arj03 / ssb-browser-demo

A secure scuttlebutt client interface running in the browser
Other
58 stars 11 forks source link

Add DHT support #281

Closed KyleMaas closed 3 years ago

KyleMaas commented 3 years ago

(Needs to be used in conjunction with the add-dht-support branch of ssb-browser-core.)

Figured I'd pick this back up again now that @staltz integrated my Hyperswarm changes into multiserver-dht version 5.0.0. As evidenced by https://github.com/arj03/ssb-browser-core/issues/43, rooms as they currently are are not terribly intuitive until you understand how they're supposed to work, and it would be awfully nice if we had DHT support for connecting without having to use more centralized infrastructure like Rooms 2.0.

This has been updated to use public versions (not based on my repos) of the DHT stuff with only a couple minor patches. This is runnable as-is and does seem to function, although there is one error that gets logged that I don't quite understand:

method:tunnel,ping is not in list of allowed methods

@arj03 Any idea what would cause this, or even if it's an error we care about?

arj03 commented 3 years ago

Can you rebase this on master and force push? Will give a bit cleaner history.

staltz commented 3 years ago

I have no objections to this PR, but @KyleMaas if you want to talk about this:

rooms as they currently are are not terribly intuitive until you understand how they're supposed to work, and it would be awfully nice if we had DHT support for connecting without having to use more centralized infrastructure like Rooms 2.0.

I'm happy to clarify rooms and their roles. They are servers, but they're not centralized (you can/should have many rooms to connect to, and once a room is down, there's nearly nothing you lose). Note that DHTs also depend on known static servers, such as bootstrap servers.

KyleMaas commented 3 years ago

I have no objections to this PR, but @KyleMaas if you want to talk about this:

rooms as they currently are are not terribly intuitive until you understand how they're supposed to work, and it would be awfully nice if we had DHT support for connecting without having to use more centralized infrastructure like Rooms 2.0.

I'm happy to clarify rooms and their roles. They are servers, but they're not centralized (you can/should have many rooms to connect to, and once a room is down, there's nearly nothing you lose). Note that DHTs also depend on known static servers, such as bootstrap servers.

Sure, I understand how they work, and it makes a lot of sense to me now that I've been working with SSB stuff for a while. (I'd still like to see Rooms 1.0 maintained even as Rooms 2.0 is launched, since they work very differently and I still see the Rooms 1.0 style of connecting to be a viable alternative.) But when I was first starting, I didn't understand how rooms and pubs worked or what the differences are, and we just had someone else that didn't understand you needed a room to connect two browser clients, so evidently I wasn't alone in this. But for a user, DHT connections are pretty simple and easily explainable. Even though the mechanism still technically relies on a pool of static servers, from a user perspective it's more automatic and turn-key than having to find a bunch of rooms and manually connect to each one. Redundancy without user complexity is I guess what I'm trying to say.

KyleMaas commented 3 years ago

Can you rebase this on master and force push? Will give a bit cleaner history.

Yeah, I can do that. And now that @staltz has that new version of ssb-dht-invite out, we don't even need to patch anymore, so it'll be even cleaner.

staltz commented 3 years ago

(I'd still like to see Rooms 1.0 maintained even as Rooms 2.0 is launched, since they work very differently and I still see the Rooms 1.0 style of connecting to be a viable alternative.)

What differences do you see? The actual connection styles are the same (and backwards compatible), what's new are aliases, which aid in the initial connection ("onboarding") in a seemless manner (and it's easier to type alice.room.com than it is to copy paste a long non-readable DHT code).

KyleMaas commented 3 years ago

(I'd still like to see Rooms 1.0 maintained even as Rooms 2.0 is launched, since they work very differently and I still see the Rooms 1.0 style of connecting to be a viable alternative.)

What differences do you see? The actual connection styles are the same (and backwards compatible), what's new are aliases, which aid in the initial connection ("onboarding") in a seemless manner (and it's easier to type alice.room.com than it is to copy paste a long non-readable DHT code).

I like that Rooms 1.0 is simple and essentially no-knowledge and anonymous (other than the obvious of IP address/ID association being available via logging). Rooms 2.0 has aliases, the admin dashboard, internal vs. external users, moderation, blocked IDs, etc. It's a much more complete and comprehensive system, yes, but it also presents a larger attack surface and most of the new features require keeping persistent state. From an administrative point of view, Rooms 1.0 is such a simple system that it's kind of a no-brainer. And it also means that, as a user, if you connect to it you'll be approved and it will work.

(Edited because I had a couple sentences out of order.)

KyleMaas commented 3 years ago

Not saying Rooms 2.0 is bad - quite to the contrary, I'm looking forward to using it. I'm just saying there are reasons why someone would want to forego the complexity.

staltz commented 3 years ago

As a spec, we're slimming it down a bit after realizing that not all those things need to be implemented. There's two things to consider: the rooms 2.0 spec (which is essentially just about aliases. "internal users" a.k.a. "members" is just there to give access rights to having an alias or not having. The admin dashboard is not strictly required) and the 1st implementation of rooms 2.0 which is go-ssb-room. I don't intend to maintain ssb-room much but go-ssb-room can be run in the same manner as room 1.0 currently, because there is the "Open" mode, which by the way:

Internal vs external, i.e. member vs non-member

This is not needed in "Open" mode in rooms 2.0, which mirrors how room 1.0 works today, and this is definitely one huge attack surface. Having anyone connect with anyone is ticking bomb. We want to have a bit more restricted access rights on purpose. It's odd that adding these features would open up more attack surface compared to "Open" rooms, specially when in go-ssb-room we're being super careful with security practices, something I can't quite assert of ssb-room.

KyleMaas commented 3 years ago

Cool. That sounds nicer. Rooms 2.0 as it was when I last looked at it seemed awfully ambitious. Good ideas, but required lots of code which means lots of debugging before it's stable.

And I mean attack surface for the room operator, not for the users. Anything which takes on persistent state is a place where a bad actor can try to inject state, and their success rate depends on your implementation. Plus, persistent state means you can't just nuke it from orbit and start over nearly as easily. And if it's the state that has the problem then your new version can also be poisoned by it. It can be done reasonably safely. It's just I expect it will take some time before all the holes are plugged. More so with how big the original goal was, but if scope is being narrowed, then securing it should be easier.

KyleMaas commented 3 years ago

Fair enough.

The DHT connection system is started in the core, but should only be for existing DHT connections. What this does is initialize the invite system, which is really only needed for the UI layer IMO, so I believe this is the appropriate place for that.

arj03 commented 3 years ago

Been testing this. Seems to work at least on the same machine :)

KyleMaas commented 3 years ago

Oh, shoot, didn't mean to force push that last one. The was unnecessary for the one-line change to package.json.

arj03 commented 3 years ago

Thanks. This is quite nice, will try it between my phone and a computer on different networks.

KyleMaas commented 3 years ago

Cool. Glad to finally have those branches cleaned up! I'm sure there will be bugs we'll have to fix, but at least now I don't have to keep extra branches updated to the master branch. Thanks!

arj03 commented 3 years ago

Testing this between a phone on 4g and my laptop on wifi and it synced a few profiles. Great work @KyleMaas!

KyleMaas commented 3 years ago

Awesome. Thanks! I hadn't tested it on a phone yet.