"legacy SSB messages" about go-ssb HOT 6 CLOSED

I take it that is how SSB currently does things.

Yes, what I call legacy here prefigures it's actually deprecation. There was a protocol meetup about three years ago, among others @dominictarr, @arj03, @AljoschaMeyer and myself, in which we all agreed that the current format (then dubbed crabby) needs to go. Mostly because implemetations need to re-create v8's JSON.stringify and also because of an initial bug of using the wrong string encoding for creating the message hashes. (See ssb/message/legacy.Verify for the gory details.)

Even though there are two viable alternatives:

1. cbor-based gabbygrove, proposed by myself leaning towards how we do things currently + off-the-shelve encoder standard.
2. the more radical/breaking and custom encoding https://github.com/AljoschaMeyer/bamboo

until now we couldn't agree on a way to transition the javascript stack to support a newer/saner format. The silverlining is that I'm working with a team on a NGI Pointer funded project to solve limitations of the protocol (mainly allowing for partial replication). Our current design draft includes a mechanism for defining new feed formats using what we dubbed meta-feeds.

I hope this helps and sorry for the chaotic documentation landscape. Apart from lot's of content on ssb itself, here are some more recent comments on the topic on github: arj03/ssb-browser-demo#257 (comment)

from go-ssb.

Would it be possible for you to note message format updates in this thread? Or is there a better place (on the Web) to subscribe to?

If you want to stay in the loop as close as possible, I fear SSB is the place to be (we write updates of our NGI work there) but I have no problem with keeping this issue open an tag it once we start working on this.

from go-ssb.

This is great news! Glad to hear this will be replaced. The JSON.stringify requirement is the main thing keeping me (and likely others) away from SSB development-wise. Happy to see those two alternatives exist and are being considered.

The documentation and development definitely does seem chaotic, at least to an outside observer like me. Would it be possible for you to note message format updates in this thread? Or is there a better place (on the Web) to subscribe to? Thanks!

from go-ssb.

So I think there are a few parts to this:

• The ability to write messages on another format to a feed locally and being able to use that feed in the query part
• A way of signaling to the world the format of a feed (this is where meta feeds come into play)
• A way to transfer other feed types between peers, EBT (js at least) should already be able to do this, we will probably also introduce a more general createhistorystream replacement that should support other feed types

So basically part 1 is as far as I know in a much better shape in GO than in JS world. Correct me if I'm wrong @cryptix. Part 2 and 3 should be developed between April and June, so if everything goes well it might be possible to test this in a few months time.

from go-ssb.

Yes! I probably need to make sure the tests are enabled but I implemented it so that the query code understands other feed suffixes already. You can do createHistoryStream --id @...ggfeed-v1 and it will give you binary cbor. Adding bamboo (or a spin-off of it) would be very simple.

The EBT code (in plugins/ebt) needs a few refactors but nothing to major. IIRC @arj03, your proposal is to have different EBT sessions/ebt.replicate duplex streams per feed format, right? That is definitely feasible with a bit of juggling.

The meta-feed stuff would require a bit of work on the graph package which right now only processes type:contact messages but with the latest proposals even that doesn't seem to far out. At least to get a complete picture of which (sub) feeds make up an identity.

In tandem I plan to rework the which feeds are fetched and which of those in full? logic. Currently I'm assuming a new configuration API to let applications drive this with more granularity. Meaning: I'd still like to satisfy the slim client use-case but also the full node/pub use-case.

from go-ssb.

The EBT code (in plugins/ebt) needs a few refactors but nothing to major. IIRC @arj03, your proposal is to have different EBT sessions/ebt.replicate duplex streams per feed format, right? That is definitely feasible with a bit of juggling.

Yes

The meta-feed stuff would require a bit of work on the graph package which right now only processes type:contact messages but with the latest proposals even that doesn't seem to far out. At least to get a complete picture of which (sub) feeds make up an identity.

In tandem I plan to rework the which feeds are fetched and which of those in full? logic. Currently I'm assuming a new configuration API to let applications drive this with more granularity. Meaning: I'd still like to satisfy the slim client use-case but also the full node/pub use-case.

Great! This sounds quite similar to the JS implementation notes I have tried sketching here

from go-ssb.