Tips and Donations System (Hivemind Implementation)
Without getting into the technical details too much, here's an overview of the implementation ideas I have, summarized from my current notes.
Tracking payments
A memo protocol to define tips/donations can be used to trigger Hivemind to record the transactions in the database. This will standardize the memo values used when sending the payments (UIs will be responsible for generating these when tipping, and these details will be hidden from users).
The memo can have two sections:
- Identifier
- Destination: Associated post (permlink) or user account name
With Native Ads, I used a protocol that resembles: hna:hive-133333/interesting-promo.
- The
hna:part is the identifier, an abbreviation of Hivemind Native Ads hive-133333is the community nameinteresting-promois the permlink of the ad post
So I will design a memo protocol for this donations system as well.
Support for goal-oriented donations
These were inspired by @midlet's recent post
In short, a user can create a "donation post" to raise funds for any goal they want to. The post will contain metadata that defines it as a donation post as well as various parameters for the fundraising, like timeframes, funding target, etc.
So when a front-end loads this post, it will have access to these properties. The Hivemind API endpoint will also avail calculated stats for that post, such as total contributions and the contributing account names.
Subscriptions (recurring payments) to support creators
Inspired by @chekohler's recent post
We could enable tips to be sent without associating a post, but an account instead, in the Destination portion of the memo protocol.
This gives front-ends options to show the following on a person's profile page or one of those profile dropdowns:
- "Send tip" button on a person's profile, which sends a tip to that person, which is only associated with that account and not any particular post.
- "Support this author" button that sets up a recurrent payment. It's only recurrent figuratively, since we don't have this functionality on the blockchain level. We could utilize a new custom JSON op to pledge
supportfor an author/account.
I suppose this can also be used on communities as well, since communities are in essence Steem accounts that can receive funding. A "Support this channel" button can be introduced.
Stats about donations
From suggestions made by @chekohler (concerning a way to see posts with the most donations like "trending"), my plan is to create endpoints that front-ends can use to access stats about donations. These can be organized by a variety of criteria such as community, tag, date, etc.
FRONT-END ISSUES
As far as the Hivemind backend work is concerned, there aren't any dependent changes that can stop me from starting work on this. However, there are front-end issues that will need to be addressed for the tipping/donations system to be implemented well:
Security of active keys and batch transactions
Right now, people use posting keys to login and perform social interactions and it's a prudent move because it safeguards funds.
There is a simple method to support tips and donations in a way that is integrated with social actions, but this simple method is not necessarily the best, for security reasons.
The simple way: just let people sign in with active keys
Though this is simple to implement, it exposes a user's liquid funds to security vulnerabilities.
Another option that branches off this one is: To enable tipping for the session by entering active key once.
Now, this introduces an elevated risk since the more times you use your active key (copy to clipboard, etc) the higher the chance of a leak.
One solution I had in mind:
Batch transactions
We could use custom JSON ops to record tips/donations, which only requires the posting key. Then these can be "pending" until a user visits their Wallet page and "releases" them, using their active key. In which case, the various transactions will need to be batch processed.
These transactions will also include the recurrent ones mentioned above, when they're due.
Hivemind can synchronize and serve this list of pending donation transactions as part of Wallet "context" through the API. The list is shown to the user for them to verify and approve.
I'm not sure if making batch transactions is possible on Steem, i.e. "one transaction containing many transactions." I couldn't find anything about it in the documentation.
Perhaps a front-end script embedded within the current Wallet session of a user that works in the background sending these individual transactions one-by-one can also work, if batch transactions aren't possible.
If batch transactions aren't possible on the blockchain level, can we make an exception for payments? Can that be proposed? Is it feasible? I'm not proficient in C++ so I can't speak on its feasibility/complexity.
What do you think? In your opinion, how best can we go about solving the front-end issues above?
Thoughts on the security issues.
So one of the things I took away from the users surveys I conducted as well as my own experience is that when we all say Steem is too hard, that's not 100% accurate. Everyone said it's easy once you learn or something along those lines. That seems pretty obvious, but I read that as in that it's not like there's a lot you have to remember or that it's actively difficult even with repeated use.
What that says to me is that it's not that using Steem is hard, it's that finding information on how to use Steem is hard. You have to scour the internet, or ask people on Discord, or the explanations that are accessible were written by people who are not very good at putting things plainly and making information accessible for people coming from a variety of levels of technical sophistication.
So to the point, I don't think frontends should "force" or push users to sign in with particular keys. I think there should be clearly written and easily accessible information on what the different keys do, and which one is appropriate for what actions. Then let the users do what they want. We are not the custodians of their security. That's their responsibility. We shouldn't sacrifice user experience for nanny security. That's what Steemit has been doing and it's not working.
Another angle
Use Keychain. This presents problems because there is no mobile version of keychain and it's a separate app that requires download and installation etc, but it only needs to be done once and it drastically improves the experience. Again, just making it part of the flow to point people to download Keychain and explain what it does clearly and concisely. Its not an ideal solution, but it's many steps forward from where we are.
The experience we want to move towards is donations/tips being about as frictionless as upvoting. It might require some different approaches to how we think about security, but I think it's worth it.
I agree. UX is top priority.
I can't recall off the top of my head where I read or heard this, but it goes something along the lines:
The app shouldn't adapt to the limitations of the blockchain at the expense of UX but the blockchain should cater to the needs of real world apps.
That said, I think Keychain is an awesome way to bridge that gap. It would be beneficial if it was highlighted more, like how MetaMask has become ubiquitous.
This is from a section of their API documentation:
Perhaps we could propose this to them to support tips/donations:
Sounds solid. Wonder if they'd be open to that. @yabapmatt
What about redirecting the user to their Wallet for any financial operations?
Sort of defeats the purpose. The whole point is to create a frictionless user experience.
Congratulations @imwatsi! You have completed the following achievement on the Steem blockchain and have been rewarded with new badge(s) :
You can view your badges on your Steem Board and compare to others on the Steem Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPTo support your work, I also upvoted your post!
Vote for @Steemitboard as a witness to get one more award and increased upvotes!
This post was shared in the Curation Collective Discord community for curators, and upvoted and resteemed by the @c-squared community account after manual review.
@c-squared runs a community witness. Please consider using one of your witness votes on us here