Inbox Implementation with Smart Contract

Hi all! New Stacks developer here. Wanted to ask for advice on a workflow for a smart contract that would help implement this: Proposal: Gaia Hub Inboxes proposal from a while back. As far as I can tell it hasn’t been implemented yet but please let me know if it has!

Effectively, it would just implement a smart contract that acts as the notification server, holding a map to lists of pending message locations, where the map key is some identifier representing the recipient. To continue with the example of Alice’s blog post on which Bob left a comment, I believe a potential workflow would be:

  1. After Bob visits Alice’s blog post and leaves a comment, Bob’s client also calls the smart contract and indicates the location of the comment (Bob’s Gaia hub) as well as Alice’s unique identifier (this may be pulled from the blog post)

  2. If Alice does not have other pending messages, the smart contract inserts Alice’s identifier as a mapping key, and sets the mapping value to a length-1 list holding the address of Bob’s message.
    If Alice does have other pending messages, the smart contract just sets the new value at Alice’s key to be the current list, with Bob’s address appended.

  3. When Alice logs in, her client reads the list at her identifier key in the smart contract. The client can then download the comments from the other users’ Gaia hubs.

  4. Once all the comments have been downloaded, Alice’s client deletes her map key from the smart contract. Alternatively, if not all comments could be downloaded (e.g. Alice’s Gaia storage is full), then only the received comments could be removed - if the comments are transferred in one-by-one, then this implementation would be as simple as setting the map value to the current list, sliced at the last received comment.

I’m wondering if this seems to have any major security flaws, or if it wouldn’t be feasible in terms of gas fees. I also wanted to confirm that it would be possible to implement end-to-end encryption in a different use-case for this contract, assuming public keys were exchanged outside of this workflow.

Also, if this has already been done, or if there’s a more intuitive way to perform this workflow in a decentralized manner, please let me know! Thanks for reading :slight_smile:

1 Like

Alex:

Would it be possible that your feature could be generalized to match the Publish-Subscribe (aka PubSub) pattern?

See Publish–subscribe pattern - Wikipedia

If so, you might get more traction on the topic and or find existing work by re-stating your feature in terms of PubSub.

What are your thoughts about this?