NOTE: Experimental thought. Is NOT meant to detract from the ongoing explorations of TOR.
What’s Secure Scuttlebut?
It’s a “protocol for building decentralized applications that work well offline and that no one person can control”. It seems like it’s mainly being used today as a decentralized facebook.
This is a good technical guide to the protocol and how it works. Read it first before continuing.
This is a more high level description and walk through of how it works and why it’s different.
Seriously, can’t you just explain it?
Did you read the guide ?
High level cliff notes:
- Full p2p network, all clients are identical, no singleton.
- A user writes data to their own “feed” on their own machine, in a git/blockchain-like data structure.
- To get some other user’s data, the user has to follow them, (think “become friends”)
- Initial discovery can be done via
pubs, which are public clients that accept connections, essentialy similar to public nodes in Grin. You get an invite from the pub, and then you connect to the pub and the pub follows you back. And you can discover other users who have done the same.
- A user also downloads additional data from the followed user’s friend graph, like second degree friends (friends of friends), or even third degree (friends of friends of friends).
- Messages can be encrypted to specific recipients, specific “friends”. So while data is shared freely on the network, only an intended recipient can read it.
- I think clients communicate over RPC. Not sure exactly how it works.
This sounds super weird
- Why don’t you give it a spin? IT WORKS.
Okay, but how is this interesting for Grin?
- Network is fully decentralized and resilient. No DHTs, no authority servers, no relays. Sure, there are pubs that bootstrap the network, but they are no different than other users on the network. They can go down, and others will go up. Users can connect to multiple pubs. It doesn’t matter.
- This structure makes it very metadata resistant. Users are going to be downloading data from each other left right and centre. Somebody passively observing the entire network will struggle to understand what’s going on.
- This system is more efficient and flexible than an SBBS. You don’t need all the nodes to download all the data. The more friends you have the more data you download, but it’s up to the users to configure how much bandwidth and data they want to use.
- It is spam-resistant. A client can publish tonnes of messages, but they only do it locally. In order for others to get that data, they have to follow them. What do you do with someone that keeps blasting stuff you don’t care about on twitter? You unfollow or mute.
- You can hide your activity from the rest of the network. You can run a private pub, where only vetted users can connect and share data and discover other users to transact with. The pub could even be a TOR hidden service.
- It offers interesting UX. So clients are recognized by public keys. But they can have vanity names that can collide. So a service could call itself “TMGOX” and would be discoverable that way, even if their actual key is different. (You would be able to distinguish real from fake accounts by their social graph, web of trust style). It could even have an
transaction categorythat is associated to their ID, that wallet developers can use when they display transaction history. This could lead to really meaningful and informative end user experiences, without sacrificing much privacy, you could do stuff like this:
This is not an exhaustive list.
Okay but what are the downsides
- As far as I can tell, the friend graph (who’s connected to who) is public. But not sure that matters much if you follow some randoms and are well connected and start downloading a lot of second and third degree data.
- It’s likely not going to instantaneous transacting, but at online/offline modes are both supported for sure. And slower transaction building makes traffic analysis harder.
- One device = one key = one data set. Which might make it hard for businesses to serve a large number of customers this way, maybe you have multiple servers or something. Not sure what the implications of that is.
- No code in Rust I think, as far as I can tell everything is NodeJS. We’d probably want to do our own thing here, much more minimal, but built on similar principles. But this would be quite a serious effort.
This is definitely not an exhaustive list.
What do you think?
Curious to hear whether this is interesting, whether there are some serious flaws in this approach, and if it can easily be picked apart. I’ve not spent too much time thinking about it, and I’m sure I’ve glanced over a lot of problems.