@silverpill @smallcircles I talked to some more ActivityPub savvy colleagues and it does look like you could technically accomplish lots of our goals with ActivityPub, if combined with Iroh for storage.
But ActivityPub is also largely underspecified, and would require extensions that many AP servers don't support.
We prefer to make a very precise protocol specification to give tight interoperability at it's core, but allow component data and schemas to develop independently for extension.
1/2
@silverpill @smallcircles That said, interoperability with ActivityPub is something we are very interested in.
I think there is a lot of opportunity for 2-way communication between ActivityPub and our data model.
---
Just for reference, this post might serve as a useful background for some of the ideas we're considering. Note that this was written before the idea of using an Entity-Component model:
https://zicklag.katharos.group/blog/how-to-federate/
2/2
>But ActivityPub is also largely underspecified
ActivityPub is not underspecified. Developers might get frustrated when they read the spec and discover that it doesn't explain how to communicate with Mastodon. But this is only because the scope of the spec is much broader. It is a protocol for building all kinds of decentralized social applications, and some of them can be quite different from micro-blogging services.
>We prefer to make a very precise protocol specification to give tight interoperability at it's core, but allow component data and schemas to develop independently for extension.
You can create an interop profile for ActivityPub which can be as precise as you want. It can be very strict and at the same time compatible with many existing applications (best practices for interop has been already discovered, and the work on formalizing them is ongoing).
Extensibility is baked in (ActivityPub is a culmination of several decades of experimentation with semantic web concepts).
Of course, you can design a different protocol, but bootstrapping protocols is a very difficult task. #ActivityPub is already popular, and it has all the properties of the Web of Data you've described in your post.
>That said, interoperability with ActivityPub is something we are very interested in.
Interoperability can be achieved by adopting ActivityPub data model (ActivityStreams 2.0). A common language will enable communication without centralized bridges. Transport protocols are secondary
@silverpill @smallcircles Interesting thoughts.
The biggest thing pushing me away from #ActivityPub is that I want a content replication system, similar to #ipfs :
- I want an efficient way to serve content to the global network and save that content offline without losing signatures of authenticity.
- I want all the data hosted by one client/server to be transparently loadable by any other client/server with permission.
- I want clients to be able to connect to each-other, without servers.
1/3
@silverpill @smallcircles #iroh which is implementing the https://willowprotocol.org/ does all those things I want from a storage, connectivity, and replication standpoint.
If I were to implement the network that I'm imagining, I think I would probably still need Iroh, even if I supported ActivityPub.
But instead of supporting ActivityPub immediately, I'm trying to understand the smallest specification that I need to accomplish my goals.
2/3
@silverpill @smallcircles If #activitypub supports everything that we need, it should be trivial to layer it on top of this protocol, possibly built-in, without needing a separate server/bridge.
But I want to build the smallest thing I need first.
I want to avoid tying myself to a protocol that has been, as far as all common implementations are concerned, implemented with different goals and trade-offs in mind.
As far as our testing and experimentation now, the more focused the better.
3/3
@zicklag @silverpill @smallcircles I wouldn't use iroh for your case. Their mutability is under iroh docs and is currently in flux. Earthstar's implementation of willow would be closer to your goals since it permits more conplex operations over the keyspace. If you aren't satisfied with AP, Noster seems closer to your constraints. I am doing p2p acrivitypub clients in @distributed for example.
@zicklag @silverpill @smallcircles Making new protocols is fun but it ends up making smaller and smaller fragments. Fewer people will wanf to adopt a thing that has no users and no apps. Building from an existing standard meand you can bring users and content to the thing that's unique about your approach faster. A lot of these new protocols are less unique than they want to think. This is coming from implementing many of them over the years.
@mauve @silverpill @smallcircles #iroh is working on support for the #willowprotocol and because I don't need meadowcap features just yet, it's safe enough for me to build on Iroh and just adapt when they come out with the willow update.
We're pretty partial to #rust so that's a big motivation to use Iroh.
@mauve @silverpill @smallcircles Something important that I don't think I've made very clear in my posts so far:
The "protocol" that I am describing is merely a minimal serialization format and schema standard on top of the #willowprotocol and nothing more.
Even the serialization format is just #borsh. It's not custom.
We aren't making a totally new protocol, we're describing a more organized way to store data on the #willowprotocol.
Granted the #willowprotocol is new and isn't #activitypub.
@mauve @silverpill @smallcircles I'm currently working on a draft specification for what we add to Willow.
@zicklag @silverpill @smallcircles Cool, I'd love a link to the repo once you have it up. Our tools at DP are protocol agnostic and we're publishing across whatever we can so this could be a nice addition some day.
Do you have a target audience for your new network?
@mauve @silverpill @smallcircles Definitely! I'll be adding the draft specification to this repo as soon as I can:
https://github.com/commune-os/agentic-fediverse
Re target audience: I think the hope is to empower user-respecting, inter-operable applications to develop easier than they could without it.
Basically, we want to support the idea of the #agenticfediverse, a concept we're still attempting to describe in the repo linked to above.
So maybe the audience is everybody who wants to be respected by their apps.
@mauve @silverpill @smallcircles
I just finished the first draft of the specification for what I'm calling the Leaf Protocol:
@zicklag nice!
In light of what @mauve said before about "smaller and smaller fragments" I wonder about selecting Borsh as binary serialization format.
It may or may not be the best choice, idk, but I wouldn't call this project created/maintained by the NEAR blockchain community the best in terms of open standards for binary serialization (Compare e.g. CBOR/CDDL).
Ostensibly small choices like that may add up in people's decision to adopt Leaf Protocol or not.
@smallcircles @mauve @silverpill Good points.
The rational for choosing Borsh is that we want a simple, binary serialization that has only one canonical byte representation for any given data.
This "one canonical representation" feature ensures that two components/schemas/etc. with the same data will get exactly the same hash, maximizing deduplication for data across the network.
I really like how simple Borsh is, but I should verify that CBOR doesn't already do what we need, too. 👍️
@zicklag @smallcircles @silverpill If you want stability in serialization you may be interested at looking at IPLD and soecifically the dag-cbor codec.
@mauve @smallcircles @silverpill After thinking more about it I realized that CBOR isn't really an option anyway because we specifically want a non-self-describing format.
This allows the description of the data to be stored separately in immutable Schemas, that Components reference by hash.
@mauve @smallcircles @silverpill So it looks like CBOR by itself doesn't have the canonical propery we need. DAG-CBOR adds that canonical property, along with the concept of CID links.
In our case we don't use CIDs, so we can't directly use either CBOR or DAG-CBOR without either adding our own specification/modifications on top or having extra stuff that we don't need.
So it seems like Borsh is still the simplest option.