In the Community Council meeting of today we discussed the possibility of introducing a Bulletin Board system for Grin as sugested by @satoshocrat. The purpose of a Bulleting board is for users to be able to share information while they are offline. These are not non interactive transactions, but are a solution that allows those users who do not like having their wallet online, or those who do not like to share their slatepacks via email or other known channels, to share that information.
The object is to a) all read up, compare these three solutions and possibly suggest others, and b) to create a bounty for implementing a well documented bare bone implementation for such a system.
This can initially be a centralized solution, but should in design allow decentralization, e.g. users should be able to deploy their own bulletin board server.
Love it! I want to thank all involved for taking up this matter swiftly. I believe it will help forge both optimism within the active user-base, and long-needed progress on the usability front.
One question I did have, as to the DDOS/Spam attack vector: why couldn’t the hosted nodes or box or relay, extract a fee as well? Perhaps from both parties as a storage / processing fee to mitigate the bloat and spam?
NVM - I like @oryhp’s - this is precisely what I was thinking as well.
I never liked the fact that sbbs can be spammed, so i like the contract invisible wall more - that is IF it works, someone would need to verify that. I’m not sure how decentralized the system can be, but assuming decentralization is not a problem then the only downside i see at the moment is that when a new person creates a wallet he can’t be the one creating an invoice.
Additionally, it requires the users to store these credits. If the user has no credits available in the wallet, they can’t use the service. An example would be if the user restored the wallet on a different machine and can’t reclaim the credits. The details of this path and how it compares to other solutions is not clear and is an area that would need to be researched.
Please correct me if I’m wrong, their DHT (kademlia) is only used for finding people. You can’t store data on the nodes. This means that people have to be online at the exact time and can’t leave a partial transaction somewhere. It seems to me like an alternative to Tor communication rather than sbbs in the sense that you try to contact a peer through some kind of routing that requires you to be online.
Indeed, it looks like they use DHT in combination with Tor. Not sure why they even need DHT since Tor does the routing on its own. My guess is they need it to link those lovely emoticon addresses that are actually the public key, to the Tor network. This dual system might also be the reason why their transactions take longer, up to 60 seconds to find a node in the network using the Distributed Hash Tabel…
In any case, it is only used for address lookup, not for providing a buffer with messages as far as I understand.
I am no expert in Tari, but I don’t believe that is the case. Their documentation says (or I thought it did)the DHT is used to post a slate when the recipient is not online.
From what I understand, grinbox is susceptible to spam attacks and/or DDOS, since there is no mechanism to “pay to post” either by PoW or fee. Whether that’s a deal-breaker or not I don’t know
You are correct, DHT is only used for peer lookup for message routing. Storing TX messages is done by theire “store and forward” extension of the DHT network.
It might be worth assessing their work on this. They’ve already made substantial effort in solving this problem, and believe they have a good solution. We should assess their implementation first, lest we find ourselves reinventing the wheel.
My concern is that bundling a solution with Grin will discourage others from developing truly awesome messaging systems with Grin.
For example, why would anyone build a Signal type messenger with Slatepack sending functionality when the SBBS “is good enough”. And wouldn’t the Signal type app then kinda be overlapping in functionality?
We should keep in mind two things:
as with Python, the standard library is where projects go to die
the pain of not having something can be a stronger motivator than having a “good enough” solution that could be a bit cooler
this is an important point. the only thing wrong with grinbox was that it didn’t have an invoicing system to prove payments and manage customers. The only thing wrong was that an item on the Grin Nice-to-haves list was not yet implemented. Which should shift our attention there, first
Can you elaborate on this please? Is there an active design proposed on the “nice to have” list? Perhaps we could even contact @lehnberg to see if he might be interested in pursuing?
There are multiple interesting solutions. Including one not yet published here, a merged mining idea from @bladedoyle with which he mentioned on KeyBase. He will write down a minimal description so we can consider this idea as well.
I would not be surprised if some parts of ideas can be combined to make one of the proposed solutions even more ideal.
For me there are a few aspects to consider for the properties a good bulletin board system should have,
Needs spam protection
Should not require a change to the core protocol
Should be easy to link to different wallet software and should be an opt-in for wallets but at the same time a standard adopted by as many as possible, just like slate-pack messages.
Preferably decentralized, but a good centralized solutions with either noise or receiving via tor or another way to anonymize/pseudonymize users would be fine as well.
I think we should not rush any decisions here. At least I myself have to still do a lot reading and discussing to grasp all the ideas. Choosing the right system, optimizing it and making sure everyone is onboard with the idea is crucial. No matter what, there will be always a trade of in properties such as simplicity, decentralization, privacy and bloat.
Great, I added the 4th proposal to the list of available Bulleting Board solutions .
Now the hard work, comparing all these solutions, thinking of implementation issues, possibly combining different aspects from different ideas. etc.
.