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.