What if... you had one Fedi account on a generic headless #ActivityPub server that simply hosts and federates your data... and had C2S UIs for microblogging, long form writing, media editing and sharing, link aggregation, games, fitness tracking, and so on, that all used that same Fedi account. Technically, it's a similar concept as ATProto (but no relay and app view) and Solid Pods (but no RDF).

It seems possible... if we can improve the AP C2S API/protocol sufficiently.

@steve

I love this vision. One hurdle I see is the lack of content types + the ability to represent them in HTML.

Bandwagon is my best use case: Albums and Tracks aren’t a standard data type. I could push those into my own AP server, but other servers wouldn’t know how to represent them correctly.

For this to work, we need a restricted subset of HTML for generating previews of unknown content.

This feature exists in oEmbed (optional) but is poorly supported on the Fediverse.

@benpate The approach I described requires us to think about servers differently. A generic AP server would only store and federate data, and would not render any user-facing content. The C2S clients would know how to render the content because they were coded to do it. Different clients might render the same content very differently for different purposes (although I see value in having the ability to share UI components too).

@benpate as long as your custom types have the current ActivityStreams Object as a base (ie, they contain a Content and a MediaType) anyone would be able to render them to some extent.

For cases where you have a different structure, you can have Profile objects alognside them linked to their Preview property. Use the vocabulary to your advantage.

@steve

@mariusor @steve

I haven't seen "profile" objects or the "preview" property in the documentation before. Am I just reading sloppily, or are these defined somewhere else?

Activity Vocabulary

Huh.. so I was just being sloppy. Thanks for the links. I don’t think I’ve ever seen those in use before!

@steve @mariusor

@benpate @steve @mariusor

For Protosocial I was musing on a role for the Profile in modeling identity. Protosocial emphasizes the actor-based nature of #ActivityPub and folllows the actor model in general.

Though these are just showerthoughts atm, a #SX solution on the wire is represented with an Application actor, which can be introspected to find the #SocialWeb services it offers, and these are accessible as service actors.

The Protosocial fediverse is an actor-based service-oriented distributed messaging architecture, combined with a linked data social and knowledge graph distributed data store.

A person should be able to have as many identities as they wish, some anonymous, some pseudonymous, some fully verified. These are all Person actors.

All actors have an ActorID, but they only identify the actor objects themself. The Profile would be a verifiable identity statement. A contextual visitor's card to pass along.