Notices by Zicklag (zicklag@mastodon.social)

@evan I actually am making a product called Weird: https://weird.one.

I need others to be able to run federated Weird instances. That requires a standardized protocol between those instances.

But the protocol is secondary. My priority is the product.

If the protocol turns out useful elsewhere, and other people want to use it and collaborate, that's a great bonus. 🥳

@evan The fact remains that things like counts and, more importantly, post replies are not viewed identically across multiple homeservers, due to the event driven nature.

There is also the fact that you don't see any post by default if you don't follow somebody and they aren't on your server. This is particularly noticeable with single-user ActivityPub instances:

https://jvns.ca/blog/2023/08/11/some-notes-on-mastodon/#downsides-to-being-on-a-single-person-server

@evan I don't disagree that you can make all kinds of interesting patterns on top of AP. AP is extremely flexible, but also requires unofficial draft extensions like LOLA to satisfy my use-case.

To make ActivityPub feasibly accomplish my goals would take more work than making my own simple solution.

And in the end I would have an increasingly complicated half-compatible version of ActivityPub, instead of a simpler protocol that does exactly what I need.

🧵

@evan As far as the risks as a product designer, there is a risk in every direction, but the simplest solution is usually the easiest to change and adapt to future needs / obstacles.

As far as wasting others' time, it can't waste the time of anybody who doesn't choose to invest their own time in it.

Every person's time is their own to invest. If Leaf isn't worth it that's up to them.

I'm simply betting my own time and effort that this will be the most effective road for me to build my app.

For the last several months I've been working on making a federated app.

I just finished migrating it to use the latest iteration of our new #leafprotocol data format on top of the #willowprotocol and so far it's going really well.

In this post I share some of the concepts and rational behind the Leaf Protocol:

https://zicklag.katharos.group/blog/introducing-leaf-protocol/

#fediverse #protocol #iroh

There are many challenges when designing federated applications. Here I share thoughts that I've been developing with the Commune group, as we envision a fediverse of agents, not a fediverse of servers.

https://zicklag.katharos.group/blog/how-to-federate/

#fediverse #iroh #p2p #decentralized #agenticfediverse

@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

@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 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 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

@silverpill Yeah, we're quite familiar with ActivityPub.

There are lots of things that go into it not being sufficient for what we're imagining, but one of the most basic limitations is that when you use actual URLs for entities, you are dependent on DNS and servers, which defeats many local-first use-cases.

Thoughts on making a "Web of Data" instead of a "Web of Pages", and how that might let us take a step away from the dominance of large, complicated browsers.

https://zicklag.katharos.group/blog/a-web-of-data/

The article is kind of a summary of responses I gave to @smallcircles 's interesting post and other replies here:

https://social.coop/@smallcircles/112778587324112948

#browser #internet #agenticfediverse #fediverse #iroh

@ntnsndr Yeah, I'm still waiting for a humble AI that knows when it doesn't know stuff. :D

@ntnsndr I use SemanticScholar. I haven't used much else, so I don't know how it compares, but it's been nice so far:

https://semanticscholar.org