Secure Scuttlebut principles for tx building

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 icon and transaction category that 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.
  • There might be friction in terms of users transacting with each other if they’ve not connected before. But I guess they could just agree to meet at a specific pub.
  • 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. :innocent:

Hmm, as @David pointed out it’s (obviously) not great if I broadcast a log of my transactions and make it available to the entire network… :expressionless:

Just from my limited experience using ManyVerse, which is a mobile client using scuttlebutt, I have the impression, that there is indeed also a DHT routed setup, as well as a local area network broadcasted and a Bluetooth backed one, to have more of a mesh network of friends. I believe you cannot outright search the DHT and follow everyone, as you can with a pub. You would need to know their addresses and/or they have to accept.

For whatever it is worth, I really like sending messages to my buddies directly on the LAN. One could argue it’s more private than the internet, even if broadcasted locally. (And yeah, possibly more of a third party app kind a thing, but still very cool. The social appeal of an app for sending money should not be underrated)

Maybe I missed the point. :slight_smile:

Coincidentally was just reading about scuttlebut, but as I understand it you can run scuttlebut over i2p or tor, in which case I don’t see the connection to grin except that someone could independently run scuttlebut in order to exchange messages and slate files. It doesn’t seem like something we would ever want to package along with grin.

I was also thinking, couldn’t you dead drop incomplete slate files digitally in public and nobody would be able to do anything with it except the person you had in mind to access it and then they could repost their slate from a different throwaway public account and only one person would be able to use it? Hiding in plain sight. I’m also probably not thinking of something. Has been a long week.

in which case I don’t see the connection to grin except that someone could independently run scuttlebut in order to exchange messages and slate files.

It was specifically for exchanging slates I was considering it.

I was also thinking, couldn’t you dead drop incomplete slate files digitally in public and nobody would be able to do anything with it except the person you had in mind to access it and then they could repost their slate from a different throwaway public account and only one person would be able to use it?

Yes absolutely, how do you do that in a way that’s standardised though (so that all wallets could support it easily) without running into a similar problem as with scuttlebutt, in that someone could monitor users on the network and correlate their postings with transactions that go on chain? I think that’s the main problem.