Why is ssb so different from scuttlebutt?
benzmuircroft opened this issue · comments
I'm not asking about the security. scuttlebutt had a model whereas ssb has feeds and scuttlebutt had an event 'update' but ssb seems to push all new updates of the feed.id though a stream.
Are you making ssb for a more specific / narrow use (different concept of behavior) or is this just early days and may you be planning to incorporate other things that you previously had that aren't feeds?
I am currently using this npm module (https://github.com/rtc-io/rtc-mesh) that has scuttlebutt installed, What I am looking into is to get the old scuttlebutt replaced with ssb (but it looks like an entirely different beast). Should I just use the security feature of original scuttlebutt and carry on as with the old or are you going to make ssb better than scuttlebutt?
Thanks
ssb shares a name an heratige with scuttlebutt, because it's based on the same abstract idea of a gossip protocol of replicated logs. but it's not gonna be compatible with scuttlebutt. In the 3 years since i wrote scuttlebutt, you are the first person to ask about security for it!
can you tell me about your usecase? What are you doing with rpc-mesh and what sort of security assurances do you need? The answer might be to use something like the old ssb-security, but to use it with more modern crypto (sodium) instead of openssl.
Oh, to answer the question of why ssb is different:
ssb is designed to approach the security question as solidly and simply as possible.
scuttlebutt was design to replicate realtime data.
although, i dabbled with adding signatures to scuttlebutt, there where still many aspects of security that weren't addressed. for example: https://github.com/ssbc/ssb-docs/blob/master/design-challenge:-sybil-attack-%5C--spam.md
I mean that in the old scuttelbutt you had
subclasses:
crdt higher-level, with sets and sequences.
r-array Replicatable Array.
r-edit Collaborative Text Editing.
append-only news feed.
scuttlebucket combine multiple scuttlebutts into one.
expiry-model memory capped model with expiring keys.
r-value replicate a single value.
gossip-object like scuttlebutt/model, but supports nested objects.
scuttleboat a dynamic scuttlebucket!
r-string character-wise collaborative text editing.
but in ssb it looks like you just have feeds. My question was rather; are you planning to implement subclasses in ssb later or shall i just use the old scuttlebutt (with security)?
You can build all of those data types on top of append-only logs (which ssb feeds are). We haven't decided whether to standardize any of them in ssb, or to just leave that to downstream libraries, but so far we've chosen the latter.
ok thanks for the info
@benzmuircroft i ask you what you are trying to do because it's a very valuable opportunity to understand how something is actually used, and what is needed, please don't just close the issue. it's super helpful to know what you are trying to do
Oh sorry dude.
Thanks for the interest! At present I have this rtc-mesh (but I've modified it quite a bit to fit my use rtc-io/rtc-mesh#13 (comment)). I've started using scuttlebutt (not ssb just yet). What I am doing with these two things is tracking the cursor movements of each user then connecting each user to another users doc through a read write stream. each user at the moment only writes his own mouse events, his face picture, and user name into one row of his own doc currently that row is named after his public uuid. but I'm planning his doc to accept text based messages from other uuid rows (other users). so In this way I am creating a temporary chat where messages only last the session of the user being on site. this will be my my temporal social layer.
What I am also looking at though is to have also is a persistent social layer. this will be associated with content items and profile pages and I think it will be more feed based like ssb!
one of my goals is to get the data to persist as long as it is popular with peers without ever having it hit my servers. I am thinking though that if the data is particularly 'your own data' (for your content/profile), then it should some how persist for you even if it has died on all other peers. so then maybe if you log back in again to the site after a long time your data could start to reappear to other peers. but I have to work on a theory of how to not make that look inconstant to other users...
Say if user A had logged out after receiving many public messages in his profile feed, then does not log back in for a long while (the other peers slowly drop his data until it dies). next user B visits user A's profile page but, because user A's data has no one sharing his feed data anymore, user B sees no feed 'no recent messages'. So user B leaves user A profile and goes to some other part of the site...
Next user A logs back in and his data comes with him (maybe from his local storage or some cloud based thing). user B then returns to user A's profile and then is confused to see a feed that wasn't there before.
Maybe I could fix this with a few default messages
- Sorry no one has shared this feed for a while, it will be back when user A logs in (why dont you give him a poke?)
- B poked A a request for his feed
- A feed was re-uploaded by A
(something along these lines) if there is not a better way to get A's feed to persist?
Sound like a good plan?
okay so ssb is targeted at the persistent social layer. what you are describing sounds a little bit like
tribler http://iptps06.cs.ucsb.edu/papers/Pouw-Tribler06.pdf
we've also discussed having ephemeral messages, but havn't implemented it yet.
ssbc/ssb-db#24
I mainly went with persistent because it was easier to reason about,
and i want people to be able to build applications on top of ssb,
so reasonability is important.
Also, if you do irc you should come hangout in #scuttlebutt (on freenode). I'm very much a believer in the idea of interproject diplomacy. just by learning from each other is helping each other's projects!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.