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-133333` is the community name
- `interesting-promo` is 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](https://beta.steemit.com/hive-136578/@midlet/the-fundraiser-a-concept-for-a-dapp-widget-feature-something)*

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](https://beta.steemit.com/hive-136578/@chekohler/subscribtions-on-steem-taking-donations-a-step-further)*

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 `support` for 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?***