Define good / hard problems we need to tackle to move ssb forward

[arj03]

Networking:

• Muxrpc
• SCTP over UDP for holepunching
• The role of pubs
• EBT
• ~Tunnel-routing~

Messages / feed identity:

• Feed format (Crappy Format, Bamboo, Gabby grove (js, spec))
• Delete messages
  • Locally is more or less there in js land, replicating a bit wonky in crappy format
  • Network wide, really depends on a new format
• Seperate key from feed (what if I could chose the feed format depending on the interaction?)
• Same-as
  • Identity Tangle
• Non-linear "feeds"
• Ephemeral feeds
  • Earthstars implementation, note their model is document based instead of feed based, but some of the same concerns apply.
• SSB observables
• Better blocking

Partial replication:

• ~Non-communitative messages (contacts, about on self)~ (obsoleted by SSB observables)
• Tangles
• Simple And Efficient Set Reconciliation
• Bamboo Point-2-Point
• Crappy hacks on crappy format
• Earthstar replication

Onboarding:

• Indexing (both locally and shared?)
• Validation
• Private messages
• Non-pub invites
  • Patchwork is stuck on ssb-friends fork
  • DHT invites
  • Tunnel invites

Blobs:

• Something different than simple gossip flooding
• Friend storage?

Private groups:

• WIP js implementation
• I also believe there is a WIP go implementation by keks

Pubs:

• Their role in the friend graph and as a way to ensure proper availability of feeds

[arj03]

Manyverse:

• https://gitlab.com/staltz/ssb-roadmap
• https://hackmd.io/-9DNiZ0NQECnfAvQ4TMgGg

[arj03]

The bug talk: https://hackmd.io/0Ks7oOT9THWyc887s0cfGw

[arj03]

@staltz I noticed you wrote muxrpc-push-stream as in progress. Can you elaborate on that? I was testing push stream the other day and it appears to be quite a lot faster. What is your opinion on streams in general in ssb? Considering we don't have the-one-who-must-not-be-named to maintain pull/push stream?

[arj03]

ARJ Onboarding, feed thoughts: https://github.com/arj03/ssb-new-format

[staltz]

@arj03 Unless my memory fails me, the-one-who-must-not-be-named said that muxrpc with push streams isn't ready yet. We could try checking with cryptix too, what he thinks about it.

[elavoie]

Can I be included on why the-one-who-must-not-be-named should not be? Is that to avoid spurious notifications? Or are there additional reasons (funny or not!)?

[arj03]

It should be this. But yeah, status wise I think you are right. I found that out the hard way with flumelog-aligned-offset that was definitely not ready yet ;-) What I'm after here is that if we are going to change some of the fundamental things (like pull stream in js land) or muxrpc, then it might make more sense to use something that was not written by dominic (the-one-who-must-not-be-named) :) And I was interested in your thoughts on that Andre. The good thing about push stream though, as an example, is that it is a 1-1 mapping api wise with pull streams so super easy to change.

[arj03]

I had a nice chat with Cryptix about this. We are going to draft up a document for a parallel network api that implements some of these ideas, mostly related to onboarding and partial replication.

[arj03]

Added some links to relevant Earthstar documents. Note their model is sufficiently different from ours that the ideas cannot be used directly, but at least the discussions give some good overview of where some of the problems lie.