3 ms·

I'm personally working on both of these problems. Multiple feeds are implementated in an Oasis PR, and multiple feed types are implemented in the protocol and G

I'm personally working on both of these problems. Multiple feeds are implementated in an Oasis PR, and multiple feed types are implemented in the protocol and Go implementation, but the JS implementation is still being worked on. Once we fix that we should be able to hold any append-only feed as a Scuttlebutt feed (e.g. a Git branch).

olah_1 6y ago
To clarify, "multiple feed types" means immutable feeds and mutable feeds? As a user, how can I know which type of feed I'm posting to? Will clients just adopt the mutable feeds by default? Or will they allow you choose the type of feed you want?
- ChristianBundy 6y ago
  Yep, sorry for the brevity -- I was on mobile. Right now the only valid message type is a JSON payload with both the content of the message and the signature embedded in the object. This has two problems: - The embedded signature is annoying because you have to surgically remove it before validating. - The embedded content is annoying because you can't delete a message without deleting the link from your signature chain. If we build validators that accept different message encodings, then we can end up with different types of feeds. Fixing the above is pretty simple: make both the signature and the content of the message appear adjacent to the the on-chain message. The signature authenticates the message, and the message references the content of the message. If you want to delete the content of the message, you can, and it doesn't require deleting the on-chain reference to its hash. Using different validators would also allow us to validate, say, Git commits, where any commit is valid as long as it contains a valid signature by the key we expect. Or maybe we validate Dat (hypercore) messages so that they're first-class citizens -- making SSB more of a meta-network for content signed with a trusted signature. My hunch is that interface developers will probably converge on a single Good Enough feed type for the application. My guess is that social network interfaces like Patchwork/Oasis will use something like GabbyGrove (CBOR + adjacent signatures and content), but that applications like Git-SSB will probably just use signed Git commits. Hard to say!

olah_1 6y ago

To clarify, "multiple feed types" means immutable feeds and mutable feeds? As a user, how can I know which type of feed I'm posting to? Will clients just adopt the mutable feeds by default? Or will they allow you choose the type of feed you want?

ChristianBundy 6y ago
Yep, sorry for the brevity -- I was on mobile. Right now the only valid message type is a JSON payload with both the content of the message and the signature embedded in the object. This has two problems: - The embedded signature is annoying because you have to surgically remove it before validating. - The embedded content is annoying because you can't delete a message without deleting the link from your signature chain. If we build validators that accept different message encodings, then we can end up with different types of feeds. Fixing the above is pretty simple: make both the signature and the content of the message appear adjacent to the the on-chain message. The signature authenticates the message, and the message references the content of the message. If you want to delete the content of the message, you can, and it doesn't require deleting the on-chain reference to its hash. Using different validators would also allow us to validate, say, Git commits, where any commit is valid as long as it contains a valid signature by the key we expect. Or maybe we validate Dat (hypercore) messages so that they're first-class citizens -- making SSB more of a meta-network for content signed with a trusted signature. My hunch is that interface developers will probably converge on a single Good Enough feed type for the application. My guess is that social network interfaces like Patchwork/Oasis will use something like GabbyGrove (CBOR + adjacent signatures and content), but that applications like Git-SSB will probably just use signed Git commits. Hard to say!