DX Requirement content format

[helge]

Continuing the discussion from Wiki: Vision for a Fedi Specification:

Hi @benpate

I started a new topic, as this will probably take a bit of back and forth. My goal is to bring the DX requirement on a content format into the Vision / Concept Template. I think that our two following points are somewhat in conflict. However, I also think that you proposed a solution with Lowest Common Denominator.

@helge

When building a recipe sharing app, a developer has to worry more about converting three tea spoons of salts into sensible units, than what the exact data structure that represents a message is, or how other applications display the recipe (if they even do).

@benpate

Obviously, every app can’t be everything to everyone (which is kinda how AP currently operates) so what are the commonalities? What is the “Lowest Common Denominator” of the Fediverse?

I’ll propose that it’s: 1) identity, and 2) notifications. My username should be the master key that opens every door on the Fediverse, and allows me to subscribe to events in a myriad of other services. In this model, my Mastodon account doesn’t need to know how music (or recipes) are handled on remote servers, but I can get access to them, and seamlessly connect to those other specialized services when I want to.

From this, I would arrive at the following:

---

Vision / Concept

An extensible minimal common content format.

Functional requirements

• [ ] The format is easily validated, e.g. exists as a json-schema that must pass.
• [ ] The format can be extended and used for multiple purposes, e.g. music sharing, recipes, micro blogging, …
• [ ] Notifications can be generated from this, e.g. “Ben shared his latest experiments on the synthesizer.”.

Non-functional requirements

• [ ] Dev guide on how to use this content format.
• [ ] Extensions can be clearly documented and recognized.

---

It is often helpful to think in analogies. If we imagine out Fedi2 as a filesystem, this common format would be like the filename with extension, date, and all other things the filesystem provides. The extensibility would be realized by files having content.

By

• [ ] Extensions can be clearly documented and recognized.

I mean that if I want to do a location based thing. I don’t just add a location property to my objects (as one would guess from ActivityStreams), but do something more. I’m not sure how I exactly I envision this. But something is needed.

Open Questions

Currently, this takes the view that minimal interactions are “being notified about new content”. This is not necessarily a social experience yet. One might want to include some interactions, or make the design that satisfies the above protocol base and make the one that allows to interact, i.e. replies / likes / shares, an extension of it.

I’m not sure which option I would prefer, or what the use cases of protocol base would be. Opinions?

[helge]

@helge

I’m not sure which option I would prefer, or what the use cases of protocol base would be. Opinions?

My initial thought on this: We should do replies as an extension, because replies are sufficiently complicated that it will ensure that the extension mechanism is sufficiently powerful / well defined:

• We need a way to say replies are: Allowed, Not allowed, Allowed when some conditions are met.
• Violate conditions such as:

@helge

[ ] Notifications can be generated from this, e.g. “Ben shared his latest experiments on the synthesizer.”.

What I mean here is that if a reply is invalid, e.g. not allowed, then it will not generate a notification.

So I think that extensions need to be split into two types:

• Functional, e.g. reply, quote toot
• Content focused, e.g. music sharing, recipes.

Content focused extensions can be seen as a specialization of functional extensions, by that they don’t add new behavior except:

There are these new fields. Here’s a wireframe on how you could display them, if you are also interested in recipes. If not, it’s cool, stick with the base I’m extending from.

[benpate]

Thanks for this excellent summary. I like all of the functional and non-functional requirements you listed out.

And I agree with your suggestion about common data vs. extensions. Something where the “required” (or lowest common denominator) stuff is present everywhere, while app-specific stuff may or may not be present.

I’d probably leave things such as “likes” and “shares” in the core set, not because of any deep principles, but just because they’re already ubiquitous.

So far, that’s pretty close to the original ActivityPub vision, yes? (I’ll add that I’d rather not dig through inconsistently formatted @context statements to see what’s available. I doubt many apps actually use that information.)

I believe the ActivityPub vision falls short because ActivityPub delivers the DATA, but not the UI to use the data. That is left up to the receiving app. So unless my app already knows how to work with recipe data (or whatever) the message is all but useless.

More and more, I’m aiming at ways to help users navigate the spaces between sites — and maintaining their state while doing so. It’s not ActivityPub, exactly, but some supplementary APIs that would make the social web more competitive with the corporate silos.

So, I keep coming back to two options:

1. Allow Fedi2 messages to link back to the originating server and include the user’s authenticated session. That way you could interact with the content on the originating site seamlessly.

2. Allow Fedi2 messages to safely embed rich content that allows users to interact with the content directly in their timelines - such as collaborating on a shared “to do” list from any server, without requiring that my server knows how a “to do” list operates.

In either case, I believe that “extension mechanism” should reach all the way up to the presentation layer, so that people can actually use our new and improved Fedi2 messages as if they’re working in a single, integrated software system.

[helge]

@benpate

I’d probably leave things such as “likes” and “shares” in the core set, not because of any deep principles, but just because they’re already ubiquitous.

After some memory triggering event, I was reminded of:

Itchi5 illustrations (@itchi5@illo.social)

The first sentence (already in the preview) complains that “Like” and “Announce” are poorly implemented in the current Fediverse. For me protocol work means something like “Do it right or not”. I would very much like to skip discussing, and thus including “Like” and “Announce” for now.

If you do not have enough of a headache related to how to implement like/announce. Consider Mastodon’s current implementation of the shares collection (I copied then anonymized):

  "shares": {
    "id": "https://mastodon.example/users/user/statuses/11350432473286/shares",
    "totalItems": 17,
    "type": "Collection"
  },

Is this a correct usage of the Collection? I do not know. I do not even want to have an opinion on it. I would need an opinion on it to discuss Like/Announce.

P.S.: I might address your other points later. This just seems important to understand my thinking on how to limit the scope.

[helge]

@benpate

So far, that’s pretty close to the original ActivityPub vision, yes?

I wrote here:

@helge

On Mastodon controlling ActivityPub: I think one of the main reasons why I am here, is that ActivityPub creates a bad power dynamic. A specification should allow people to read it, and then decide if something is right or wrong. ActivityPub does not pass this bar. Instead one asks “Will it federate with Mastodon?” However, the details of the situation are unimportant. What matters is that we want to develop a new approach that allows one to avoid these type of situations.

The thing is not that ActivityPub is a bad basis for creating an application that federates. The problem is that ActivityPub is a bad basis for two independent people to create applications that federate. I also allude to it here, one could take the outbox part of ActivityPub and build something that entirely works with static site generators. Unfortunately, this will not interoperate with the current inbox based Fediverse.

For me the goal needs to be “Create a protocol. Two independent implementations of it, will interoperate”.

---

The second thing is: I’m not in a position to judge what the original ActivityPub vision it. I don’t think it’s written down somewhere.

[helge]

@benpate

So, I keep coming back to two options:

1. Allow Fedi2 messages to link back to the originating server and include the user’s authenticated session. That way you could interact with the content on the originating site seamlessly.
2. Allow Fedi2 messages to safely embed rich content that allows users to interact with the content directly in their timelines - such as collaborating on a shared “to do” list from any server, without requiring that my server knows how a “to do” list operates.

In either case, I believe that “extension mechanism” should reach all the way up to the presentation layer, so that people can actually use our new and improved Fedi2 messages as if they’re working in a single, integrated software system.

I like these ideas and think that it is important to explore the question “What should our extension mechanism be capable of?” We should probably collect it in a vision / concept, e.g.:

Vision / Concept

A rich extension mechanism for providing additional optional features.

Functional requirements

• [ ] Allow Fedi2 messages to link back to the originating server and include the user’s authenticated session. That way you could interact with the content on the originating site seamlessly.
• [ ] Allow Fedi2 messages to safely embed rich content that allows users to interact with the content directly in their timelines - such as collaborating on a shared “to do” list from any server, without requiring that my server knows how a “to do” list operates.

Non-functional requirements

• [ ] Item 1: Brief explainer
• [ ] Item 2: …

I think the key here is to be optional. For example the hypothetical be succinct service that only allows messages with 140 characters or less, cannot be forced to display more. I have ideas for a lot of “interoperate less” services. That limit what can be displayed. I think one should be able to go into both directions. This is very much my vision and nothing concrete at the moment.