RE: Let's Talk About Fees & Functionality Coming in the @tippy Text-to-Tip Service!
My thoughts on functionality are not so much at this point in time. I suggest to launch it soon and let the people who try it come up with suggestions, it is always better to learn in practice then in theory. One suggestion I have, move ASAP to a button in the Steemit UI, as well as Busy.org UI...but preferably only Steemit UI now, by far the most users on Steemit UI + it gives a benefit to the Steemit UI to use for those who like to tip. The comment phrase looks simple, but people will make mistakes. For Steemit INC it is almost no work to get a button in their UI.
On transaction/tipping fee. I agree some fee shall be applied since development is not for free. You could implement a transaction fee as you suggested, in a later phase you could also implement a subscription fee, ie for x Steem per month a user is allowed to tip y times. From making revenue, this subscription fees are always interesting since people tend to forget they paying a fee, while may not use the service for some time. I understand your thoughts in low percentage for small amounts and higher percentage for larger amounts. I also understand @ned, when have a lower amount on a higher tip/transaction, people may be incentives to send higher tips. BUT, with most of use earning free money by blogging/commenting/curating, I don't think these arguments will work. But why not testing this? I would go for simplicity at launch, 1 single percentage regardless of the tip/transaction value. Any service becomes successful for its simplicity, ie Simplicity is the KEY element in any service. The percentage itself, well that is a balance between what the users are willing to pay for and what your costs are that went into creating this. One very proven and successful pricing strategy is in any service coming to market is, free from the beginning, and at some point in time start asking money for it. At that point you will loose customers, but while the service was free you will gain more customer than if it was not for free. I've seen that many times in many different countries with SMS pricing and SMS services pricing. Whenever those was made free or much less expensive, the usage went sky high, after applying the normal pricing again, the usage came down, but usually the usage was higher than before such SMS-for-free campaign. Another thing to think about is, how you like the community to perceive your service, but also you as a person. That also determines how you price the service. Do you like progressive systems? Like out tax systems, the more you earn the more you have to pay in relative terms? I don't, therefore I like contant fees, either in relative terms or in absolute terms, but no progression or digression. But commercially that may not be the best pricing strategy.
Wow. Now THIS is thoughts and feedback. Thank you for taking the time to write what is on your mind.
I'd love for my code to make it into the site and be officially implemented so I can gloat to my non-existant friends in real life that I created a service used by a multi-million dollar network. However I'd not really even set that as my goal until you mentioned it.. I'll perhaps have to ask the Steemit INC crew what needs done on my end to get tippy ready to rock and roll on the GUI.
I'd briefly played with the idea of a subscription style service rolled into @tippy and the way you describe x amount of tips free would be interesting. Perhaps have a $1SBD, $5SBD, $20SBD, etc etc optional monthly subscription that would allow chargless tipping and perhaps even access to advanced functionality.
I really appreciate you brainstorming with me. Perhaps a constant fee and subscription offering is the way to go.
Cheers man.
I would launch with either: absolute contant fee, or constant percentage. The advantage of the later is that someone who want s to tip a really low amount can do that without paying up to 100%+ on commission. Since we have many many mini mini mini minnows int he community making a couple of cents on their post, I would suggest to go with a fixed percentage at start. Be aware your service may get a lot of hits when introducing such pricing strategy, bot may be created that tip 1.000s of tips within seconds, maybe sending 1000 account each 0.001 Steem. So have a plan ready how to mitigate this when it happens. You do not want to have an real outage on your service. So when your service is not able to handle many tx per second, you may want to introduce with a tx fee constant in absolute value, this will reduce the amount of tips generated. Oh, from engineering point of fee, think how you can throttle the tip requests, with meaningful feedback to the tippers when their tips are not possible to be accepted.
I'm thinking some sort of queue system that serves multiple tippy accounts in round robin should be enough to handle high service loads.. However I'd not even given thought to users making bots to mess with it.. I'll have to do some research and testing once I get my load handling / 20 second limiter work around functioning.
From software architecture point of view I cannot really contribute, I know a bit from working with software architects as a pre sales guy and product manager, but am far from a specialist :) DB is important though, lot of developers decide for easy and go with non redundant. 20 tx/sec seems very low performance. You will see very busy times and very not busy times. I'm pretty sure, but only live tests will show you real figures. Maybe launch the service without announcing it to the community but with some early adopters you recruit directly? Limit the number of users to use the service, just to see how in that trial period the tippers are behaving? But then again, if you state alpha testing and you give some guarantee the tips never gets lost, than it should also be fine to roll out to the complete community. When you ask no fee from the start, you take a issue away, or at least partially...when things go wrong, nobody could claim and point fingers at you saying "you earned even money from us!". All the sht happening with the Poloniex exchange last week(s) I so furious about, since they cause market drops but earn at least 300k US$ worth of tx fees, and still they do not get their sht together with constant outages of their service, and leaving their customers with losses on their portfolios. Anyway, not completely comparable with a tipping service, but still, where money is involved people start to get extra emotional.
One great thing about running a service on a blockchain is it's nearly impossible to lose deposits as it's all recorded in public.
I've been pretty meticulous about how user data is stored, accessed, written and used. I think what I'll end up doing is ditching the variable fees and going to a flat rate.
As for closed beta testing I could likely implement some sort of whitelist function that would allow only those who've been approved to access the service.
When dealing with deposits, balances, transfers and fees there is no margin for error and the system has got to be potato-proof as well as intuitive, secure and have redundancy / backups. I'm probably 50% done the code I reckon.. It will likely be another week of coding and a week of testing before I'm entirely comfortable unleashing this.
That was why I asked :)
Great!
WOW that is fast work! But my reference are larger engineering departement with all sort of middle managed and lots of processes and extensive testing blah blah blah, but I know things could go much faster when we would not have those processes, documentation etc etc in place...but yeh, my customers demanded such organisation.
I'm an insomniac.. So my natural sleep cycle is roughly 48 hours awake and 12-16 hours down time. Believe it or not I do my best work and find the most ambition in the wee hours of the morning when any normal human being would be resting for work..
Problem with large teams is that you have dependencies and bottlenecks within your group most of the time and that kills output as well as creates situations where you may introduce flaws or bugs in the system when adding people's code..
Atleast with the 1 man army style of development I've got no one to blame but myself if bugs arise and the entire project is all but mapped out, just a matter of getting it to function as intended, tested and launched!
You are absolutely right! I hope I was a bit of help to you. I always love it when people come of with cool services and are able to implemented them. I can only think of them, create the concept, market and sell it. Unfortunately I cannot code, but maybe fortunately as well, since everybody has their talents and mine is not necessarily coding, although I like to work with software people :) Wil be waiting for the service! :) Happy coding in the mean time :)
Actually, to be fair, I suggested a lower fee percentage for greater sums would better than the reverse (higher percentage for greater sums), but that a flat fee percentage is probably the way to go. I also suggested and pointed out quite a few other things about tip bots - including the risks for the operator and users, especially if they are to scale.
@tippy tip ned 0.1 steem
@ned
Shouldn't a tipping purse be something that Steemit, Inc. can integrate on the site through the UI? I know I've mentioned this in the past - having an option to fill a smaller purse with an amount of STEEM/SBDs that can be tipped to users on the post with the click of a button when logged in with the posting key. Do you think that would be feasible as a wallet/UI function?
If this could be done, then it would also help bring in more potential earnings for older posts that are past the payout window...while the reader is right there on the post. (Of course, this would also assume that older posts can actually be found by simple navigation around the platform, but that's another development that needs to be tackled.)
One - upvotes are tips.
Two - transfers, which anyone can use for tips, could be implemented on the article pages - but users would need active keys. Transfers from articles pages are essentially the same function as transfers from steem wallet pages.
A smaller purse, like you described, could be accomplished as a new account balance with its own key authority - call it the tipping till - controlled by the tipping key. But this can be seen as largely a naming convention. It reflects what can already done between regular accounts and savings accounts.
My short answer is that it is possible - anything is possible, but that we will not be putting this on Steemit's near term development roadmap - as I pointed out much of the functionality already exists.
Right. But upvotes don't count when the post is more than 7 days old. And if you want to give more than an upvote, you'd need to send it manually.
OK. That was my question - whether or not a tipping purse could handle a transaction without needing to sign in with active/owner keys. The point would be to streamline tipping when you're signed in for posting or voting and to make tipping as simple as an upvote. Any additional steps that would be required would make the function sort of pointless.
I didn't want users to have to use their keys in any way shape or form. In essence @tippy is like a reloadable debit card that you can spend faster than conventional STEEM/SBD. Which reminds me I need to get tip memos working properly so users can tip to exchanges / shapeshift or other services that require the memo field for deposits.
Part of the reason I'd started on this project months ago is to be able to avoid clicking on buttons as much as possible to streamline the way we tip eachother on here.
Although if by some miracle Steemit Inc extends interest in implementing the @tippy functionality into the GUI I'd gladly work with them to get it done. :D
Well, I actually think that clicking a button would be quicker and easier than writing it out in a comment. And it wouldn't require a lot of space in the blocks either, as minimal as it may be.
But I do appreciate the work you're putting in. At least somebody is doing it.
You've come a long way, @klye! Although, your many MS Paint drawings are missed.
A button might be easier.. Like a small "Tip" icon by usernames that only requires you type in the ammount and select currency.
I'm going to continue to develop and finish the text-to-tip service @tippy offers regardless of buttons on the front end. The idea of not having to leave a post to toss a tip at a favourite user greatly appeals to me. :)
Thanks man, I miss doodling as it was so much less complicated but I'm honestly really enjoying the code work and the challenge of creating things that will benefit our network and her users. :)
Maybe one day once everything is set up and running smoothly I can get back to my roots and start drawing like I did. Truth be told I miss doing the art and having folks actually be stoked to see my illustrations.
i agree.
Tip bots like any other instant service requires a solid foundation, ie scalability is to be solved from the ground up in day one, as well as availability. Especially a tipping service requires business critical availability since people get frustrated when it doesn't work. And frustrated people are bad for the success of the service. What also is very important is the absolute flawless handling of the tips, ie once accepted by the system, it shall never be lost, so data redundancy is required. @klye will the tip administration and value recording be done on the Steem blockchain? Or will the service gets its own DB?
The current version stores its user data in a custom structured database. However I do really like the idea of somehow having all user data and stats info stored on the STEEM blockchain..! I'm not sure I'll be able to figure that out in the 2 week deadline I've given myself but if by chance I do have a breakthrough on STEEM blockchain storage of data I'll certainly be attempting an implementation in future versions.
Just make sure to have a redundant DB and make sure when you have accepted a tip, the DB storage of the tip is accepted as well by the DB. This also counts for the deliver part of the tip. I suggest you make the accept and deliver patch independent, that seems to work better int he workflow, and you can for instance accept more tips incoming then sending out in high load situations. But, such engineering requires more work. I come from an industry where most of the engineering effort went into solidifying the software then the actual features the user sees; Required for business critical system with availability figures of 5 9's.
I'm thinking I might flat fee it.. Seems to be what most would prefer!
Might be a little over tired having been up all night working on @tippy.. If I misinterpreted or botched what ideas you'd put forward to me when brainstorming my apologies captain!
There are risks as you mentioned when dealing with user funds as well as risk that government may take notice and try and ding operators for transmitting money without a license. APpreciate the insight and knowledge you've shared with me as well as the support of my STEEM service development. <3
What about autotipping by upvotes? This is implemented in Dobrobot in Golos. Works fine for me! On each my upvote Dobrobot transfers 5 Golos to user which is upvoted by me.
Interesting idea! Are there any caps on how much Golos is available to tip with the posting key?
It is fixed amount of Golos you define in memo field when transfer your donation fund to Dobrobot account. Dobrobot has no caps on it, I think, but it is not a problem to add such caps in code. It is better to deploy such bots by trusted person in the community. Dobrobot uses its active key to transfer funds.
For example, I transfer 100 Golos to @dobrobot with memo: 5.
This means that on each my upvote @dobrobot will send 5 Golos to upvoted account. So I have 20 upvotes before I get a message Your donation fund is empty, please refill.
Anytime I can change this Golos per upvote number to 10 by transfering minimum 0.01 Golos with memo: 10.
I'm just the author of the idea. The developer of the bot is @ropox.
Useful links:
https://golos.io/@dobrobot/transfers
https://gropox.github.io/dobrobot/?dobrobot=dobrobot&minBlock=5691376
https://github.com/gropox/dobrobot
https://web.telegram.org/#/im?p=@chain_cf
Damn! That is some neat functionality for sure!
Just getting into deposit memo functions on my bot now. Got a bunch accomplished today but will certainly check this lead out. Thank you.
@tippy tip edje 0.1 steem
this is what I got in my wallet:
3 hours ago Receive 0.099 STEEM from tippy Tip from @klye via @tippy memo: Text to Tip Service - 1.00% Fee: 0.001
This works!
Can you make the command like this? "@tippy edje 0.1"?
This makes it more simple. Tip will then always by Steem, so not possible to tip with SBD, but that should be fine, or? You could consider to put @ sign in front of recipient, this is what Steemit user are accustomed to, but not sure if that works for your application. Ohw, also note the . and , are in USA different to eg Europe. Not sure if possible, but if both can be accepted as the same ie 0.1 = 0,1 would cause maybe some less errors.
In text messaging and especially USSD (not sure of you know that from your mobile) they usually use some extra markers in from of the text message to identify it is a command. It will complicate things a bit, but may also become more recognisable as a command rather than a comment. Characters like # * are used, but I guess this may be not wise with Steemit's markdown editor and different meaning to those symbols.
I could implement that command structure if you'd like. Anything is possible.
Could use a $ in front of the integer to tell the bot to send SBD... Will have to play with it a bit.
Got powerups working now too. You can use your steem balance to power up others via tippy now. :)
I'm still working on functions then going to attempt to integrate STEEM blockchain backups and whatnot. Then I need to tackle the queue / post limit evasion and get the restart block checker going and we should be good for some insanity testing. :D
I would not include to many functions at launch, these will be better determined by the feedback you'll getting from the users. More functions also makes it more complex. Better to spend time on making the backend work in a resilient manner :) But that is just my 2cents :)
You may keep what you have now, but be prepared to change it. All depends on how many mistakes that users are gonna make. An idea could be to create some browser plugin that helps creating the command; ie a little menu to include recipient, value and currency. But this has there own challenges + more work to create, so keep that as a possible extension sometime after launch, ie candidate roadmap feature. I would start with only Steem, keep it simple, see how the users like it. It also drives demand for Steem since post are payed out in SBD when selecting the 50/50% :)
I've basically got the beast tipping SBD / STEEM / Powering up STEEM / Handling Deposits / Balances / Fee forwarding and a handful of other things.
It's not actually that difficult to build a fully feautured tip bot. The hard part will come with bullet proofing it and integrating with the STEEM blockchain.
I can always allow both styles of tipping.. Not a big deal. Functionality is already built just need to change the triggers around a bit.
Correct! That I know of software engineering, features are usually easy, in my line of business we call this marketing stuff. The real stuff, stability, resilience, scalability, integrations with other system are the difficult parts. When done that right, with top level performance vs hardware resources, you enter the game of high value IT software for which millions of $ are requested from customers.