You are reading content from Scuttlebutt
@aljoscha %0eJLwmZ8uePGPtoTx4PAq8ZwhVOmcMxWwBSQHpobzCM=.sha256
Re: %L9m5nHRqp

@andrestaltz_phone

Quick question: would it be easy to fetch 'about' messages (which are typically early in the feed)?

That's a separate concern. The whole feed infrastructure is unopinionated about replication rpcs. The obvious ones are still full feed replication and random-acces via hash (aka ooo but with security guarantees). But of course it is possible to build others as plugins.

A really sweet spot between efficiency and expressiveness/granularity could be prefixes of message types. So you'd say "I have feed @foo at sequence number 42, but only those messages whose type starts either with about or chess::." The peer could then check whether it has any messages newer than seqnum 42 whose type matches one of the prefixes and send them.

This could be implemented pretty efficiently by sending around radix trees of the type prefixes. And the empty radix tree could be special-cased to mean "I replicate the full feed".

A different, much more expressive (and thus inefficient and complex) plugin could allow sending code in a query language, or even some sort of non-turingcomplete programming language (à la dhall) for computing at the peer's machine what kind of messages to retrieve.

And on the other end of the complexity spectrum, you could just build a plugin that exposes an rpc that does nothing but exchanging about messages.


I haven't made up my mind whether I would want to have something like the prefix-based pubsub in the core rpc set, but I think if we want something in-between full-feed replication and ooo as a core rpc, then it is a very good candidate.

Join Scuttlebutt now