Discussion & Feedback: Decentralized Social Message Board Platform on Algorand #86
Comments
HashMapsData2Value
changed the title
ExampleI populated my own tx history (sent to my own address just for the sake of testing) with some messages, and then I did some testing. My standard is:
First I wish to see the last 10 messages on the ALL topic. The prefix is We get the following raw data: We have two messages here. They're sorted by most recent (highest block height):
We see Alice is shouting greetings into the void. Did people have any reactions to this? Let's find out. This time the prefix is
This time we have three messages!
Seems like people felt some kind of away about Alice's second message! Now, let's tune into a specific channel/topic/sub? Prefix is
Actually I screwed up and sent the same message twice hehe. But the note here is Hmm, kind of extreme. Let's see if anyone has anything to say about that? Prefix:
Message is: Uh-oh. Seems like someone thinks this is hate speech? if we deeply care about what List of Messages/Transactions
ConclusionAs can be seen, at the risk of spamming poor AlgoExplorer's API, it is possible to create some rich interactions on-chain and find/filter them easily by ensuring that the messaging format fits will with the PrefixSearch query. |
|
Thanks for writing this up! Interesting idea and I like the concept. I'd like to consider some alternative storage like arweave or ipfs for the actual posts and have the note field be limited to some hash of the contents. The reason for this is that I'd like to limit the size of the messages to prevent an entire social networks history from being committed in the blocks. While a post might be allowed ~1k bytes, sufficient for a raw tweet, any additional content like an image would not fit unless it was a link to some other storage solution. We'd have to have a link off to some larger storage solution anyway, so it seems reasonable to have the post content be stored in the same way. We'd definitely want to consider some alternative indexer to the vanilla one provided by Algorand that is capable of watching blocks and flagging/indexing any that are relevant to this ARC. |
|
Maybe it could be worth looking at http://www.agorhash.com/ (there is a link to the open-source repository too) which could be seen as a first rough attempt to implement something similar to what you proposed. In this case the messaging protocol is ASA-based both to manage posts and "tokenized-likes". Maybe there could be some synergy. |
|
In my conception for truly decentralized messaging, the message is encrypted with the target recipient's public key and posted on a "data chain" with many other messages encrypted for other users that are in the same "chatroom", and users can just scroll through, attempting to decrypt each one. Everything that makes sense gets communicated, and there's added obscurity because messages have no obvious recipient. There's a little cryptography wizardry to be done to get from the signature keys on Algorand to encryption keys, but someone could figure it out given time. There's added security with this because the addresses that send the messages can be fresh every time which allows for a system that's pretty darn hard to trace. Smart contracts can hold 128 key-value pairs with the sum of their lengths equaling 128 bytes or so. In my conception I had a chain of smart contracts as a history, and then each slot except the first and last can be a reference to a transaction, and there the note field would hold the message. The first and last slots would hold the previous "data" block and the next "data" block. Then you have the interaction with the contract be a group transaction that references the head of the data chain, as well as a governance smart contract that determines which addresses can post, etc. Each data chain is a "chatroom" The nice thing about this is that your referenced transaction in the message slots can have in its note another referenced transaction at the end of the note, allowing messages of any length by chaining them, submitting the message backwards before committing it to the data chain. The application ID of the current data chain head could be stored in the governance contract and auto-populated by the web application that interacts with the data chain, so you would just need the governance contract head application ID to send messages, everything else could be handled behind the scenes. |
I think moving the messages to some other decentralized data storage is an obvious improvement on one hand, but I'm wondering how much the size of the TX note matters. My intuition is that the Algorand blockchain is growing so fast anyway, at some point archiver nodes will probably start pruning TX notes and only keep the hash of the transaction, at which point it wouldn't matter if we have 1k bytes or an IPFS link. Archivers specifically focused on servicing this platform could prune any TX note of any TX not directed to the address in question - as you say, we'd want an alternative indexer that deals with this. (Idk if you guys in the Inc thought about something like this already for other business cases? I'd imagine having the ability to quickly setup a "biased archiver" could further lower the barrier of entry for many apps. You'd just need to setup caching and and an api gateway in front of it to have a simple backend for whatever blockchain application you could think of that depends on storing data immutable data on chain.) As has been mentioned, it does start to matter if you want to be able to write longer articles and keep them in one place, as opposed to chaining messages together. The downside of relying on that is having to run both an Algorand node and a separate IPFS node. One nice feature of IPFS is that the link is based on the hash of the content, such that no one could tamper with their own message/content after making a link to it. |
I didnt know about them but that's cool! The downside is that Agorhash is a token created and mostly held by an individual, which seems unnecessary when you could just use Algo directly and just send 0 Algo messages to an account. They sort speech by the Agorhash transaction amount. It's actually ingenious in that you automatically get a free version (just opt into Agorhash and send 0 of it to the reserve account) and a premium version (spend extra), but it's not conducive to creating an inclusive protocol with many actors at each level. Purposefully upping your transaction fee is much more egalitarian :-) |
|
@acheel3dv
I think the conversation on this ARC draft is quite good. It's about encrypted private messaging. One question, besides the danger of mixing keys like this, is how it works with rekeying. I definitely like the idea of using the key-value store in smart contracts in some way, I haven't given much thought about how that could be utilized. |
My understanding is that you can gain the "speech" token through "likes" so the more the ecosystem likes your posts the more you can spend to give your post visibility.
Actually I think that the use of a specific ASA has also a "technical advantage": retrieving information searching among specific ASA transactions is much more efficient than searching information among all the ALGO transactions. |
From the page it says that:
Since AGORHASH would have a real value in ALGO through any DEX, I might as well short-circuit the process and just gift you ALGO directly that you can use to boost your transaction fee and have your post become more visible.
Relevant docs. It's not note searching among all the ALGO transactions ( In Agorhash's case they're both using an asset id AND sending it to a reserve account, so it's not clear which API call for note searching they are using. If you know for certain that the Ultimately:
|
HashMapsData2Value
changed the title
|
As discussed with @HashMapsData2Value, I close this issue |
Introduction
This is a discussion and request for feedback on a proposal I have for creating decentralized social news/networking (Reddit, Twitter, forums etc) on top of a decentralized network and database like Algorand.
Why Algorand?
Performance
Algorand can currently sustain ~1000 TPS, is set to be upgraded to ~10k TPS in the near future and eventually ~46k TPS. It has the performance to support a lot of activity.
Each transaction cost 0.001 Algo and can carry a transaction note with 1000 bytes. This is more than enough to carry metadata + message payload, or information representing some other kind of social media engagement and do so at a very low cost (fractions of a ¢).
Algorand has instant finality/does not fork, meaning that you don't have to wait some extra seconds/minutes to be sure that your post won't disappear.
Blockchain History Growth
Algorand's node setup, where participation nodes only need to remember the last 1000 transactions + account balance + smart contract state means that the blockchain history can (and will) keep on growing without necessarily affecting the barrier of entry for new node runners.
In fact, from last I heard, the blockchain history is close to approx 1 TB but a participation node running in non-archival mode only needs ~11 GB. (According to the Foundation having 100GB SSD is recommended but that's beyond what is necessary at this time.) In short, this means that - unlike some other blockchains, whose representatives I have occasionally seen take pride in having a "small size" - Algorand's blockchain size is free to just keep growing.
There's a Built-in Indexer!
A node can also be run in Archival Indexer mode. (Note that all Relay Nodes must run in Archival mode). Archival means that it stores all the history, and Indexer mode means that the Indexer is activated. Algorand's Indexer software is a PostgreSQL Database with a REST API. Conveniently, because the indexer engine indexes transactions note fields as well, it is possible to do a prefix search for a transaction - either for a specific account
/accounts/{account-id}/transactions, or a specific asset-id/assets/{asset-id}/transactions, or ALL/transactions. We can piggy back off of this and simply work on creating a suitable messaging standard that works with this prefix-search. (People are of course free to create new indexers to allow for richer search patterns.)Algorand's Approach to the Right to be Forgotten
Algorand was specifically designed to conform with the Right to be Forgotten - though of course it is up to node runners to choose if they want to conform to it or not.
This is possibly because Algorand, like e.g. Ethereum, is a Balance-Based Blockchain(BBB). On Page 4 ("Problem with Legacy Blockchain"), Silvio explains why other blockchains like Bitcoin, based on UTXO, cannot conform to RTBF.
Specifically:
This means that nodes can actually choose to "forget" a transaction note (message/post/tweet/etc) and only keep the hash, without it affecting the integrity of the blockchain history. The person who originally wrote that transaction note, or anyone else, will still be able to prove afterwards that they wrote a specific thing by providing their original message to be hashed and comparing it to the hash stored in the blockchain.
One might ask why we would consider this a good thing? Isn't the whole point that we DON'T want any kind of censorship? Well, as I said, it's up to each node runner to decide what they want to keep. But one immediate concern is that people would use a decentralized social platform to post illegal content, like links to child pornography. Instead of requiring this to be filtered away at the UI-level, node runners can choose to self-censor it from their own databases, avoiding any legal (or moral) repercussions of having to store that kind of information.
Proposal
Layers
Using Algorand as the very base and core of a decentralized platform, I am proposing and requesting feedback on the following multi-layer proposal. The point is that each layer will be open for competition, with people and companies either providing something as-a-service, or self-hosting.
Node Layer
Base layer is of course the Algorand blockchain. Anyone can run a node already. If you only want the ability to post messages, but not necessarily care about the ability to to query for messages all the way back to geneis, a non-archival participation node is enough. If you want to self-host the whole thing, or provide it as a service for others, you can do that too by running in Archival-mode + Indexer-mode.
Data Layer
This refers to the contents of the transaction note and the message formating standard we'd device. The following metadata should be included in a note:
My suggestion is that people stick to writing to a specific account, e.g.
VANITYADDRESS4ALGORANDDECENTRALIZEDSOCIALMESSAGINGPLATFORM(assuming that's a valid address) to help concentrate the messages into one place for the entities on the Aggregation Layer to find them. Even in the astronomically low case that someone manages to generate that account, the point is not for people to send Algo to it. All messages should be 0 Algo, though the transaction fee might be changed (see [3]).Direct/Private Messaging could also be possible, though I have not mentioned it here. It would require using encryption which complicates things at this stage. There is an ongoing discussion on this as part of an "AlgoSMS" service, as suggested by Pawel.
The actual formatting of this information should, as mentioned, be optimized for prefix search.
[1] - More could be done here. It might be that for obfuscation/privacy reasons multiple people wish to use the same Algorand account to post from, and be able to jump between various shared accounts, instead relying on some kind of proof they can include into the message that it's the same person. For example, some kind of succinct non-interactive ZKP proof of a secret that only the owner of a specific handle would know. The 1000 byte limit does put a limit here of what's possible.
[2] - A discussion could be made on whether or not "following"/"subscribing" to someone should be something you post on the blockchain. Personally even though it is pertinent information to give out to the world, I think it would clutter things up a little too much. My suggestion is that people can keep a list of accounts they want to follow off-chain. Then the Aggregation Layer or UI Layer can take that in. They'll also be able to give their engagements/reactions to those messages and the Aggregation Layer can use that for recommendations.
[3] - An interesting feature would be to give people the option of increasing their transaction fee to REALLY show that they engage strongly with a particular message, giving feedback to the Aggregation Layer. The reason why it is better to do this through the transaction fee and not by sending Algo directly is that transaction fees are recycled in Algorand and are brought back as rewards, whereas sending Algo to an address is the same as burning them.
[4] - Decentralized and free platform or not, curation can be good. In a Subreddit you have moderators that manage a subreddit, Facebook groups give the option for Admins to review posts, etc. The idea is that auto-moderators and human reviews could be introduced to give their own input here by donning the "Curator" hat. Messages can be flagged as spam (though the economics of the blockchain penalizes dumb spam), transaction notes not following the specified format can be flagged as malformed, suspicious links can be flagged as malware, genocidal/hateful/threatening messages can flagged as incendiary speech, links to illegal content like CP can be flagged as illegal content, and so on. Archival nodes can use this info to prune their own storage to avoid filling up their databases with spam and Aggregation Layer can use it to NOT recommend you stuff (based off of your provided list of Curators). Even the UI Layer could use it, e.g. for parents. Of course, if you want the PURE unfiltered experience then you are free to run your own node, aggregation engine etc.
Aggregation Layer
We need some way to filter all the messages, some kind of aggregator that sits in front of the end user (UI Layer) and the underlying archiver node. There are two parts here:
Basic Filtering: What did people reply to me and my posts? What are the new posts within topic X (minus stuff flaggad by my trusted Curators as Spam)? I follow Silvio, did he write anything recently?
Recommendation Engine: Given the list of people and topics I follow, my account's previous engagement, the engagement of OTHER people who are like me (given a definition of "similarity"), what do you recommend next?
People are always fighting over "the Algorthim". Here my idea is "Bring-Your-Own-Algorithm".
If you wish to provide it as a service to others, you can do that too. (You might do it for free and slip some stuff into the "fineprint" about recommending ads...)
If someone wants to self-host their own aggregation algorithm and fine tune exactly the type of messages they wish to receive, have full control over calibrating their own bubble and echo-chamber, they can do that too.
UI Layer
Finally, unless the user wants to read the messages themselves in pure markup/notation, they need some kind of UI layer. People might want different skins on their web page, they might want have access to this through their mobile phone, etc.
UI Layer entities would also be responsible for ensuring that messages sent to nodes are properly formatted. They need Wallet Connect. They would load the links and media (which could be from IPFS) and interpret any special characters.
As a Co-Chain
Building this thing on top of Algorand will allow the platform to immediately benefit from the security and decentralization guarantees that come with Algorand's main chain, owing to its momentum and vibrant community.
However, if there is not enough bandwidth to host a platform like this within Algorand, or that it risks drowning out all other activities on the blockchain, it might be worth creating a co-chain of Algorand specifically for this with its own native token. Then you simply use state proofs on both ends to create a bridge, allowing you to spend Algos to buy [insert name of token] to be used for paying for your activity.
This co-chain could also streamline its own Indexer as well as restructure things on a protocol level. Not just play around with the fee structure, but also bigger changes like increase the 1000 byte limit (if needed) or introduce some privacy features.
But we're unlikely to require this for a long time.
Conclusion
What are people's thoughts on this?
The text was updated successfully, but these errors were encountered: