mastodon.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
The original server operated by the Mastodon gGmbH non-profit

Administered by:

Server stats:

383K
active users

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.

zicklag.katharos.group/blog/a-

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

social.coop/@smallcircles/1127

zicklag.katharos.groupA Web of DataThoughts 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.

@zicklag @smallcircles

>Imagine an alternative internet protocol were each “thing” on the internet is an “Entity”. Entities might represent blog articles, chat messages, tweets, comments, or anything else. Each entity also has a path to that entity, like a URL.

This protocol is called "ActivityPub". Objects are entities, their IDs are paths, and their properties are components.

https://www.w3.org/TR/activitypub/

www.w3.orgActivityPubThe ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

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

@zicklag ActivityPub IDs are URIs, and URIs don't always require DNS or servers. That depends on URI scheme.

One AP-compatible URI scheme with key-based naming authority is described in FEP-ef61. This FEP discusses HTTP transport, but the object format is designed to be transport agnostic. It is suitable for local-first applications too

@smallcircles

www.w3.orgActivityPubThe ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

@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

Zicklag

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

zicklag.katharos.group/blog/ho

2/2

zicklag.katharos.groupHow to Federate?Thoughts on the challenges and design of federated software.

@zicklag @smallcircles

>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 is that I want a content replication system, similar to :
- 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 which is implementing the 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

willowprotocol.orgWillow Specifications - WillowProtocols for synchronisable data stores. The best parts? Fine-grained permissions, a keen approach to privacy, destructive edits, and a dainty bandwidth and memory footprint.

@silverpill @smallcircles If 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 @smallcircles

Makes sense.

I'm not familiar with iroh but if it supports mutable data pointers (in contrast to immutable pointers like CIDs in IPFS), it should be possible to use iroh together with FEP-ef61 flavor of ActivityPub.

@silverpill
May be worth looking into #Autonomi which has both content addressable storage and append only 'mutable' registers, so you have a complete history, and local first support because those registers are also #crdts.

I've built a demo versioned web publisher/browser on it.

I've wondered too about how to do social/AP but will figure that out later. My priority is a secure cloud like #p2p storage network without any servers, gatekeepers or dictators.

@smallcircles @zicklag

@happyborg @silverpill @smallcircles One thing I like about the is that it doesn't create an infinitely growing append-only log with a permanent record of every change. Sometimes you want to be able to delete revisions and clean stuff up to save on storage.

The idea is instead to let you track versions with maybe something like a `Revisions` component that has a list of the immutable entity snapshots of older revisions.

@zicklag
Storage shouldn't be an issue on Autonomi, at least that is the goal.

I create a lot of data on my laptop but when I buy a new laptop it all fits in a tiny percentage of the new machine.

Autonomi aims to provide this for all uploaded data, so the Internet Archive/Wayback Machine can be built into every public website.

It feels counter intuitive but we only need look at projects like the Internet Archive to see it may be possible, so my view is let's try!
@silverpill @smallcircles

@happyborg @silverpill @smallcircles Is there any plan to make Autonomi Open Source? It does look intresting.

I still feel that no deletions becomes a problem if I'm doing video editing and the artifact that I'm changing may be many gigabytes of data. I don't want to keep the old versions in that case.

Storage is getting cheaper, but it's still limited.

@zicklag
It is and always has been FOSS. Currently GPL and my own stuff is AGPL. I'll no longer contribute to anything MIT etc but GPL is good enough for me.

There may be use cases where you don't want to store online forever of course, and maybe local first / sync use patterns can help there.

Anyway, I thought it sounded relevant.
@silverpill @smallcircles

@happyborg Autonomi is really cool; greatly appreciate all the work you do!

Unfortunately (A)GPL prohibits the source-available app layer we wanna build on top of our (permissively licensed) protocol.

I’ve worked professionally with GPL for many years and in short it doesn’t have the necessary dynamics to facilitate a healthy self-hosting ecosystem. I don’t wanna start a whole sub thread about it here so expect a dedicated post in the future.

@erlend

I look forward to reading it, and particularly what you mean by:

> a healthy self-hosting ecosystem

@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 is working on support for the 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 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 and nothing more.

Even the serialization format is just . It's not custom.

We aren't making a totally new protocol, we're describing a more organized way to store data on the .

Granted the is new and isn't .

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

github.com/commune-os/agentic-

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 , 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.

GitHubGitHub - commune-os/agentic-fediverse: An outline and resources for the "Agentic Fediverse".An outline and resources for the "Agentic Fediverse". - commune-os/agentic-fediverse

@mauve @silverpill @smallcircles

I just finished the first draft of the specification for what I'm calling the Leaf Protocol:

mastodon.social/@zicklag/11281

@sotolf

It's so fascinating to me that the Web was this dead simple documentation format that required only a fairly lightweight browser to view the content. But now it's a sprawling application platform from hell where each website is a bespoke infernal application that does God knows what while excruciatingly rendering its data to the user.

I know it's a very dumb solution to a very complex problem, but I do kinda love #Gemini for this.

@silverpill @smallcircles @zicklag

>> But ActivityPub is also largely underspecified

> ActivityPub is not underspecified. … It is a protocol for building all kinds of decentralized social applications.

Which results in it being underspecified for any specific application (especially if interop is a goal). But it’s an interesting spin. ;-) As others have noted over the years, #ActivityPub more of a sketch or outline of an idea than a protocol.

@steve @silverpill @smallcircles @zicklag I think a lot of harm has happened because of the dominance of #Mastodon, and not because of ActivityPub spec's limitations. Mastodon was built as a Twitter clone - an app where users both create and consume the `Note` object type. It ignores all the other object types.

This forced all other ActivityPub apps (eg: Pixelfed) to shoehorn their content into a `Note`. Though, Mastodon is soon going to support `Article` object type.

@admin @silverpill @smallcircles @zicklag I don't expect Mastodon to solve this. Their leadership seems to think like how bigtech platforms think (get user traction even if it means compromising the health of the ecosystem).

The key idea is that #ActivityPub generalizes the idea of email inbox to give everyone an inbox AND an outbox in the cloud for all kind of objects, not just messages. There's very little need to split this inbox/outbox into a dozen different apps.

w3.org/TR/activitystreams-voca

@nilesh @smallcircles @zicklag @admin Although the data model of activity model is extensible and supports schemas and constraints through related technologies, it is also a problem that working knowledge of how to leverage those technologies is not well known. Nor are there great libraries for it outside of Java and node fwict

@nilesh @smallcircles @zicklag @admin But yeah, it would be great if more social networks tried to map their graphs using activity pub concepts. Like lemmy/mobin could have a group/community be an inbox than went it receives a message it creates another inbox that is for the specific post/thread

@nilesh @smallcircles @zicklag @admin Or a link aggregation site does does something similar, but also has events/activities for +1/-1/liking a comment/etc

@steve @smallcircles @zicklag ActivityPub is underspecified in the same way HTML is underspecified. It's a feature, not a bug.

The spec can be improved, of course, but I don't think it is a sketch.

@silverpill @smallcircles @steve @zicklag That’s an odd comparison, between a so-called protocol and a markup language. In any case, I’d claim HTML is *far* better specified than ActivityPub.

An age-old problem.

Transfer protocols:
HTTP
ActivityPub
E/SMTP

information formatting specifications:
HTML
ActivityStreams
RFC822

@mikedev @smallcircles @steve @zicklag
Yes, it would be more correct to compare HTML with ActivityStreams. I just tend to think of AS and AP as a single standard.

@steve @smallcircles @zicklag Yet people somehow created hundreds of ActivityPub applications. If anything, it is over-specified. Inbox, outbox and ActivityStreams are the foundation, everything else should be in FEPs describing specific use cases

Having built other transfer protocols for ActivityStreams, I would probably agree. Nomad for instance doesn't have an inbox; which is an unnecessary implementation detail. It has a server-wide delivery endpoint and a delivery "envelope" - much like SMTP,  but encrypted.  And it does not try to define relationships. But this is getting off topic. The "web of data" in the original post of this thread seems to relate much more to information structure than transfer protocols. And it appears the Leaf Protocol has gone off in another direction anyhow.

@silverpill @smallcircles @zicklag As you've already said, implementing ActivityPub/AS2 as-specified isn't going to work well in most cases. Mastodon took the AP sketch and filled in many gaps to make it workable. Other (most?) Fedi apps copied that. That isn't evidence that AP isn't underspecified in many respects. It also doesn't mean it isn't overspecified in other areas (as you claim). One issue doesn't preclude the other.