I think one of the pillars of the core protocol for the Fediverse should cover the two Gherkin features: Basic functionality and Follow requests. The two features will probably evolve a bit with stuff like messaging the follower collection.
-
I think one of the pillars of the core protocol for the Fediverse should cover the two Gherkin features: Basic functionality and Follow requests. The two features will probably evolve a bit with stuff like messaging the follower collection.
Everything else can be extensions. In particular, storing stuff in a way accessible by third parties is a hard problem. A good way to do this would be the second pillar.
The big advantage of separating the pillars is that one can declare the first pillar done, while the second one is still a big question mark. Also this would allow one to work on improving the first pillar "syndication" with things like batching, or how to sign that only affect it.
-
@helge so you mean that the core protocol has a very small surface area, and the rest are optional features ("extensions") more or less implemented/supported by the Fediverse participants (the "apps")?
(But only one protocol?)
-
I'm not sure what the goal should be. However, current ActivityPub and talk about its "extensions" is icky. Hrefna has quite a few posts describing the ickyness.
It's better to look at a good example: HTTP.
- httpS can be considered an extension of http. Nobody needs to care about how it works, there are tools, e.g. nginx that take care of it.
- Adding the
X-Look-Mom
header can be considered a HTTP extension. I can imagine 10 year old me doing it. It's very easy. - Adding a new status code is more involved
- Adding a new http method would be a large undertaking (I read something about query).
My point here is that HTTP has clear extension points (headers) and stuff that should stay constant (format, methods). This is missing from ActivityPub. The pillar of the core protocol could be where one starts defining things that are constant ...
-