Zicklag
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:
silverpill
>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.
silverpill
@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
Zicklag
@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
@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
>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
Zicklag
@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
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.
Zicklag
@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
Zicklag
@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
Zicklag
@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
Steve Bate
@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.
nilesh
@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.
silverpill
@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
@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
Steve Bate
@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.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.