Replacing AP+[reverse-engineering Mastodon defaults] with AP+FEPs

[strypey]

I’ve already derailed the SocialWebFoundation - what do people think? thead enough, so to continue the discussion about vanilla AP …

@trwnh

Do you see the fediverse as a sort of digital service which people connect to in order to make and read posts on the fediverse? Or would you rather see people publishing and browsing resources on the Web?

Matrix can be used both for publishing on the web, and reliably private communication with a specific person or group of people. The existing fediverse is mainly the former, with limited and fragmented support for the latter. It sounds like you want to ditch the latter completely. A lot of the noise I hear on the verse wants the verse so be entirely the latter. I ask them, as I ask you, can it not be both?

@trwnh

“implementing enough of the core AP spec to have some level of interop with other software that does the same” doesn’t describe the fediverse at all. You could implement the entirety of ActivityPub and not be able to talk to a single person

Agreed. Implementing vanilla AP is (or ideally ought to be) necessary but not sufficient. Creating a satisfying fediverse UX traditionally involves AP+[reverse-engineering Mastodon defaults]. The purpose of the FEP process, as I understand it, is to move us towards something more like AP+[base FEPs for…]. If you want what most people think of the traditional fediverse experience, what follows the “FEPs for …” would be “microblogging”. But if you want to interoperate with PeerTube and OwnCast, what follows … would be “video sharing”. If you want to interoperate with Mobilizon and Gancio, it would be “event invitations”, and so on. Crucially, an app that wanted to incorporate two or more of these experiences could do that, by implementing more than one set of FEPs.

@trwnh

I think that “minimal core + extension FEPs” is an okay model for things

Consensus!

@trwnh

but right now the core is too minimal (we have no specified way to let a follower know that they’ve been removed!) and the extensions haven’t been written (as FEPs or otherwise).

I hear others arguing that the core is too opinionated, on things that are not core. It’s probably a bit of both. Properly fixing it would probably require breaking changes. IMHO these are best prototyped as FEPs. Then they can be rigorously studied and tested in the SWICG, before a charter is sought to standardise an AP 2.0 (or a completely new successor protocol spec, or whatever).

In other words, I think @aschrijver is right about the 3 stage pipeline for protocol dev; rapid prototyping, battle testing, standardisation.

@bumblefudge

[Mastodon] made monolithic clientic-servers the “de facto standard”-

@trwnh

It’s not only “not optimal”, but it is also actively harmful

Agreed. I remember Christine LW explaining the original AP vision for being able to use different web apps for different purposes, all logging in to the same server, thanks to all servers and apps implementing the AP c2s spec. So when I want to browse or publish videos, I’d be able to use the web app on a PeerTube server to login to my account on a Mastodon server. It continues to frustrate me that we are denied these benefits, because the default approach to developing for the fediverse is a monolithic server+web-app, in the Mastodon mould.

On a related note, I’m constantly pushing for developers to pick either a server, or a web app (or native app) to work on, based on their skills and what itch they’re trying to scratch. Rather than thinking they have to do both, because that’s what Mastodon and the other flagship projects did.

I can’t remember if I ever posted it or not, but I drafted a series of posts arguing that Mastodon ought to focus on being a web app, and outsource their server development. To people who actually know how to do it efficiently, and optimise for a network of many small servers, rather than a network of a handful of big ones. FWIW Bridge Seat Co-ops original target was to host Akkoma with the Mastodon web app as default. Because Mastodon’s Ruby-on-Rails server is the Spruce Goose of fediverse servers, which can only be kept in the air by bolting on more engines as the weight of passengers and freight increases

[trwnh]

i apologize in advance if this response is a bit short because honestly i’m reaching the point in the overall conversation where i don’t think it’s productive to continue, but

@strypey

It sounds like you want to ditch the latter completely

unless i’m misunderstanding the referent ordering here, this is the exact opposite of what i was saying. i’m in favor of the Social Web and not the Fediverse Social Media Service Platform. i’m not saying we should immediately ditch the “platform” but i think we should move away from it toward a new paradigm. one that’s less focused on a context-collapse “global town square” and more focused on actually keeping things in context.

[codenamedmitri]

Fwiw, I do think it would be a fun and useful intellectual exercise, to straight up make a two-column table, with Mastodon features on the left, and corresponding FEPs on the right. “This are the FEPs you need to re-create a rough approximation of Mastodon API” sort of thing.

[thisismissem]

Could I just ask that we don’t use the term Mastodon API here, since that refers to the API that Mastodon provides, not the AP implementation that Mastodon has. The two aren’t the same.

Perhaps: “AP + Mastodon profile”, based on ActivityPub - Mastodon documentation ?

[trwnh]

i think the convention is to refer to the client access thing as an “API” and the server-to-server federation as a “protocol” (even though the way mastodon works, it would be more accurate to call it “client-to-client” or “instance-to-instance”)

[strypey]

@codenamedmitri

Fwiw, I do think it would be a fun and useful intellectual exercise, to straight up make a two-column table, with Mastodon features on the left, and corresponding FEPs on the right.

This seems like a sensible and actionable idea.

quote=“thisismissem, post:4, topic:4596”]
Could I just ask that we don’t use the term Mastodon API here…
[/quote]

Totally fair. We do need something less unwieldy than “AP+[reverse-engineering Mastodon defaults” though

@thisismissem

Perhaps: “AP + Mastodon profile”

Sounds good to me. Or “AP+Mastodon defaults”. Either would do.

[silverpill]

@strypey

Creating a satisfying fediverse UX traditionally involves AP+[reverse-engineering Mastodon defaults].

You don’t need to reverse-engineer Mastodon defaults (whatever that means) to create Fediverse software. Mastodon is not special. Yes, it has a number of annoying bugs and quirks, but every other implementation has them too, this is simply a price you have to pay to be a part of decentralized network.

That being said, it is true that most existing ActivityPub implementations converged on a single protocol, which is slightly different from the written spec. I have a document where I’m collecting various undocumented features and requirements of this protocol.

I’d call it “living spec”.

@strypey

The purpose of the FEP process, as I understand it, is to move us towards something more like AP+[base FEPs for…].

Yes, but I don’t think that “a FEP for micro-blogging” makes sense, because there’s no such thing as “Fediverse micro-blogging protocol” or “Fediverse video sharing protocol”. FEPs describing specific features are much more useful.

[trwnh]

@silverpill

I don’t think that “a FEP for micro-blogging” makes sense, because there’s no such thing as “Fediverse micro-blogging protocol” or “Fediverse video sharing protocol”.

There’s a (non-singular) protocol for “posts” that isn’t described by either ActivityPub or by your “ActivityPub for developers” FEP draft. I think it absolutely makes sense to survey and describe what it takes for different softwares to convert your activity into a local entity. How should the activity be shaped? Which properties are required? What is the lifecycle of any given object? Every single implementation “quirk” is an unstated requirement of some implicit protocol.

[silverpill]

I agree that “posts” is a good subject for a FEP, but I wouldn’t call that a “micro-blogging protocol”. After all, forums and video-sharing services have comments too.

Actually, it is briefly mentioned in my doc, in “Duck typing” section:

Use duck typing when processing objects. For example, an object with attributedTo and content properties can be classified as “post”.

In my view, it’s a feature. Services that don’t support it might still be interoperable with micro-blogging apps (example: a boost bot may not care what it is boosting).

[strypey]

@silverpill

You don’t need to reverse-engineer Mastodon defaults (whatever that means) to create Fediverse software. Mastodon is not special.

Mastodon is, in many ways, a terrible example of AP implementation. But it is special, because it’s currently the software that most servers in the fediverse run, and that most people with fediverse accounts use. So most people trying to figure out how to make their new app talk “fediverse” do it by studying how Mastodon works (you can’t just read the docs, so that’s why I say “reverse-engineer”). Because when they follow the spec to the letter, they inevitably end up with something that doesn’t allow accounts on their servers to communicate with most other fediverse accounts.

In other words, although…

@strypey

Implementing vanilla AP is (or ideally ought to be) necessary but not sufficient

… you seem to be mistaking this ideal for the reality. Which really just gets in the way of moving towards it.

@silverpill

I don’t think that “a FEP for micro-blogging” makes sense, because there’s no such thing as “Fediverse micro-blogging protocol” or “Fediverse video sharing protocol”. FEPs describing specific features are much more useful.

When I say AP+[FEPs for microblogging], what I mean is that if Bob is creating a microblogging app, following the vanilla AP spec is nowhere near enough (see above), so Bob will also need to implement some FEPs. But which ones?

AP+[every FEP] is going to be far too much. As the FEP process continues, there will probably be groups of FEPs specific to specific use cases (livestreaming, for example), that a microblogging app doesn’t need to bother with.

There may also be FEPs for things that could be beneficial in microblogging, but are very tricky to implement well (eg E2EE). So we probably wouldn’t include these in [FEPs for microblogging] either. Or if we did, we’d probably list them under ‘can use’, whereas WebFinger would be under ‘must use’, as things stand.

Anyway, the project @codenamedmitri suggested for this thread is to define an AP+[FEPs for Mastodon compatibility], which given the implementation reality described above, seems like a good place to start. If you don’t feel like that’s a good use of your time, no worries, you’ve got plenty of important stuff to work on

[stevebate]

@strypey

It continues to frustrate me that we are denied these benefits, because the default approach to developing for the fediverse is a monolithic server+web-app, in the Mastodon mould.

I don’t fully understand this (the issues of the “monolithic” implementation, not just your statement). Yes, Mastodon has a user-facing client aspect and a server aspect, but those don’t seem excessively coupled to me. I use Mastodon frequently without a Mastodon-provided client on my mobile devices. If I didn’t like the Mastodon advanced UI as much as I do on the desktop, I could use Elk or Sengi or another browser-based client. If I did, I would only be using Mastodon as a pure server (using their API) for posting notes/statuses (versus admin, which is different).

I believe one reason for the “default approach” is that the AP C2S is not suitable for a decent UX. The Mastodon API is better in that sense, but obviously it’s not based on ActivityPub. Server developers have a choice: write their own client or implement the server-side of the Mastodon API to support Mastodon Clients (I can already hear @thisismissem screaming about that option, ). Both options are not great for different reasons (unless the server development team has an awesome UX designer, which seems to be rare).

I’m looking forward to seeing the list of FEPs that represent AP+Mastodon federation behavior.

[silverpill]

@strypey

Mastodon is, in many ways, a terrible example of AP implementation.

In what ways it is terrible?

[thisismissem]

@stevebate

I believe one reason for the “default approach” is that the AP C2S is not suitable for a decent UX. The Mastodon API is better in that sense, but obviously it’s not based on ActivityPub. Server developers have a choice: write their own client or implement the server-side of the Mastodon API to support Mastodon Clients (I can already hear @thisismissem screaming about that option, ). Both options are not great for different reasons (unless the server development team has an awesome UX designer, which seems to be rare).

@stevebate damn right I’d say C2S should have more endpoints defined to make it useful for client applications, e.g., there’s something I’ve heard about which are Collection Views (like database views), such could be used on the inbox to create something more akin to the Home timeline that users are familiar with.

[stevebate]

@thisismissem

I’d say C2S should have more endpoints defined to make it useful for client applications, e.g., there’s something I’ve heard about which are Collection Views (like database views), such could be used on the inbox to create something more akin to the Home timeline that users are familiar with.

I agree that C2S should (must) be extended if we want it to be useful for client applications. It won’t be a small project, but it would be interesting.

Would the Collection View use event sourcing of the inbox and outbox activities to produce a filtered stream of objects? Assuming people use local and federated timelines (I don’t and don’t even use my home timeline directly), those are a bit more challenging to support (but still doable).

Mastodon-style user-defined list-based and hashtag timelines have some different considerations.

Ideally, I’d like to see a design that allows for user-defined and shareable filtering (beyond simple text matches), ranking, and maybe tagging of posts in custom timelines. That goes beyond what Mastodon offers and could motivate developers to make the switch.

I use the bookmark capability of Mastodon quite a lot. It could be added as a special collection in C2S, but the “streams” standard endpoint is so underspecified that it may be difficult to use for referring to the collection (or collections if multiple bookmark collections are supported). I suppose the good news is that it’s so underspecified that most servers don’t use it for anything at the moment.

Event streaming is probably not extremely difficult to add (probably needs new standard endpoints), but I’m not so sure about search, which can be more complex than one would think.

Of course, there’s all the other missing stuff like authorization …

Maybe this more on-topic for the ActivityPub 2.0 new features thread.

[thisismissem]

@stevebate

Maybe this more on-topic for the ActivityPub 2.0 new features thread.

Or it’s own thread entirely “Extending C2S to be more useful for Rich Client Applications (in an S2S world)”

@stevebate

Would the Collection View use event sourcing of the inbox and outbox activities to produce a filtered stream of objects?

That’s my understanding of that. This is Collection View: fep/fep/5bf0/fep-5bf0.md at main - fediverse/fep - Codeberg.org

[kopper]

This is starting to come close to one of my primary grumbles about AP C2S (as a concept, entirely) so I may as well barge chime in the conversation.

What is the true point of C2S? What is the server’s role in C2S? To be a dumb pipe, like IMAP, that other applications may be built on top of? Or something that’s more aware of the specific objects passing through, and has specialized handling (e.g. maintaining timelines)?

If it’s just supposed to be a dumb pipe, then you just can’t have any features or UX improvements that would differentiate your client from others, unless it was also hosted in a server and effectively duplicated the data already stored in the C2S server’s database, for no good reason.

If it’s smarter, then at what point do you just re-create an AS2-flavored Mastodon API? With similar interoperability problems of S2S tacked on as a bonus due to the lack of specification of contemporary AS2? (made even worse by the fact that we’re talking about C2S and not S2S)

Is “Sorry, but your ActivityPub server does not support home timelines/bookmarks” a valid error message a C2S client should ever produce? How are C2S client developers meant to create (what I believe to be) novel-to-AP functionality like the Cohost following pane without modifying the server, in a reasonably efficient manner? (e.g. without needing to individually query every single actor’s outbox), when servers with custom APIs don’t need to think about all this and can just go ahead and implement it in a day or two.

Is this even a goal for C2S?

[hamishcampbell]

Might be worth using the #4opens as a tool to put a bit of push on Mastodon.

The #4opens are a simple way to judge the value of an “alt/grassroots” tech project.

Open data – is the basic part of a project https://en.wikipedia.org/wiki/Open_data without this open they cannot work.

You can get your data out with RSS and AP and vie user export, so TICK

Open source – as in “free software” https://en.wikipedia.org/wiki/Free_software this keeps development healthy by increasing interconnectedness and bringing in serendipity. The Open licences are the “lock” that keep the first two in place, what we have isn’t perfect, but they do expand the area of “trust” that a project needs to work, creative commons is a start here.

It has a #FOSS licence TICK

Open “industrial” standards – this is a little understood but core open, it’s what the open internet and WWW are built from. Here is an outline https://en.wikipedia.org/wiki/Open_standard

Here it’s problematic, it supports atom/RSS good, but is AP support is pushing broken HALF TICK

Open process – this is the most “nebulous” part, examples of the work flow would be wikis and activity streams. Projects are built on linking trust networks, so open process is the “glue” that binds the links together. https://en.wikipedia.org/wiki/Process

It uses #github a #dotcons platform, which kinda has open process but is in meany ways unresponsive to this #openprocess HALF TICK

Solidarity

It’s easy to become a 4opens project and join the openweb family. Just show that your project fulfils 2 or more of the above “opens”.

2 opens - Bronze badge
3 opens - Silver badge
4 opens - Gold badge

This makes 3 opens, so Mastodon is a silver #4opens project, to become gold it needs to improve its standards competence and/or work at better open process.

[trwnh]

@kopper

What is the true point of C2S? What is the server’s role in C2S? To be a dumb pipe, like IMAP, that other applications may be built on top of? Or something that’s more aware of the specific objects passing through, and has specialized handling (e.g. maintaining timelines)?

mostly a dumb pipe, but there are a few side effects defined in ActivityPub for certain activity subtypes. i think the best aay to conceptualize C2S is to consider what happens with an extension activity. a vanilla c2s server will not understand it and will not be able to process any side effects for it, but that doesn’t mean it can’t do anything with it. functionally we can say that the primarily role of a c2s server is to deliver according to the addressing properties to/cc/audience. if the local server doesn’t understand the activity then maybe the remote server will. if the remote server doesn’t understand the activity then maybe some client reading the inbox will.

@kopper

If it’s just supposed to be a dumb pipe, then you just can’t have any features or UX improvements that would differentiate your client from others, unless it was also hosted in a server and effectively duplicated the data already stored in the C2S server’s database, for no good reason.

the client effectively uses your server as a storage and delivery backend. if it needs to pull stuff out of the inbox to do further processing then yes, it probably ends up needing to cache the server data in its own local client storage. but you still have a wide variety of clients possible. you could have mastodon be a client and pixelfed be a client and then connect them both to the same actor on the same server, and your posts will sent out to the saem followers and you have access to the same social graph. and if you want to use some social game client, then it could send activities without having to implement all of the federation and delivery logic for itself.

@kopper

Is “Sorry, but your ActivityPub server does not support home timelines/bookmarks” a valid error message a C2S client should ever produce? How are C2S client developers meant to create (what I believe to be) novel-to-AP functionality like the Cohost following pane without modifying the server, in a reasonably efficient manner? (e.g. without needing to individually query every single actor’s outbox), when servers with custom APIs don’t need to think about all this and can just go ahead and implement it in a day or two.

clients generally should not run into issues of feature support like this because the features exist in the client (which may itself be a server-side application). there’s no concept of a “home timeline” in the spec, only an “inbox”. to construct a “home timeline” you would need to possibly query or filter your inbox for specific types of notifications (Create, Announce), which is arguably missing functionality at this point. (we really could use a generic querying/filtering endpoint but the leading option in this is SPARQL, which is basically SQL but with namespace support, and writing raw queries is not something most devs wanna do, so their only current option is to page through the inbox as needed.)

the way to “just go ahead and implement” something like cohost’s following pane is to page through the inbox for relevant activities and construct your LRU cache (LRR? least recently read?) based on what you get out. of course this has to happen client-side because there’s currently no mechanism to keep track of which notification activities have been “seen” or “read”. i think there’s a FEP that tries to define a special collection of ViewRecord objects, but there s probably a better way if we sit down and really think about it.

imo there’s not much difference between having your db in a monolithic app be your source of truth vs. having it be a cache in your server-side client. the only real difficulty right now is in syncing any sort of state between clients. the only thing that all clients have in common is they read from the same inbox and/or post to the same outbox. i don’t think there’s a place to put arbitrary data or records on the actor, like there is in atproto or solid, but activitypub as a whole wasn’t meant to address arbitrary storage, just arbitrary delivery of notifications. to get a good “storage experience” you’ll probably end up needing to complement activitypub with other specs, either in the form of a single multi-protocol server, or separate servers more or less acting as microservices (e.g. the storage server could implement solid, the delivery server could implement activitypub, and then some client of both can construct activities that refer to resources hosted within solid but delivered to your activitypub social graph.)

[kopper]

@trwnh

mostly a dumb pipe, but there are a few side effects defined in ActivityPub for certain activity subtypes. i think the best aay to conceptualize C2S is to consider what happens with an extension activity. a vanilla c2s server will not understand it and will not be able to process any side effects for it, but that doesn’t mean it can’t do anything with it. functionally we can say that the primarily role of a c2s server is to deliver according to the addressing properties to/cc/audience. if the local server doesn’t understand the activity then maybe the remote server will. if the remote server doesn’t understand the activity then maybe some client reading the inbox will.

@trwnh

the client effectively uses your server as a storage and delivery backend. if it needs to pull stuff out of the inbox to do further processing then yes, it probably ends up needing to cache the server data in its own local client storage. but you still have a wide variety of clients possible. you could have mastodon be a client and pixelfed be a client and then connect them both to the same actor on the same server, and your posts will sent out to the saem followers and you have access to the same social graph. and if you want to use some social game client, then it could send activities without having to implement all of the federation and delivery logic for itself.

Yeah, this is more or less what I ended up abbreviating as simply a “dumb pipe”. If you imagine the “client local cache” as backed by some form of easily queriable (probably relational) database then it’s not hard to imagine how everything else fits in (until the time comes where you need to synchronize them from scratch, which you touch on near the end). This is also the design I’d lean on if I was looking into building something around C2S myself.

The main thing confusing me around the discussion around C2S (not just here) is the comparison to the Mastodon (client) API. Even with C2S you’d still need a bespoke client API (assuming you’re not rendering HTML pages serverside) for client-specific functionality like the aforementioned cohost feature. I feel like not everyone’s on the same page about the meaning of “client” here.

I also have worries about duplicating data both on the C2S server’s storage and the client’s own cache as that’s one point of inefficiency removed if you bundle them together like most contemporary implementations do.

One thing I like about the AP ecosystem is that you can host a totally usable single-user instance with all the bells and whistles and custom extensions you want, in machines as low end as a 4 EUR/mo VPS. After just a year of uptime my own instance uses ~8GB out of the 38GB storage available, just for it’s database. (granted, this is without any pruning of unnecessary remote objects) And in such situations it’s really helpful to minimize these inefficient parts as much as possible, and unlike media storage (which I’ve yet to get billed for as I never cache remote media, and my local use is small enough that I can run off the free limits of my provider), the kinds of storage that make sense for databases aren’t exactly cheap.

[trwnh]

@kopper

I also have worries about duplicating data both on the C2S server’s storage and the client’s own cache as that’s one point of inefficiency removed if you bundle them together like most contemporary implementations do.

eh, it’s like saying thunderbird or claws-mail should come with their own built-in integrated imap+smtp server. having the storage and delivery abstracted away is really useful and i don’t think everyone should be expected to build the equivalent of a mail server while also being expected to built the equivalent of a web browser. it should be possible to build on other people’s work instead of constantly reimplementing the same federation logic over and over in subtly incompatible ways.

any “inefficiency” of having to cache inbox data in the client database is vastly counteracted by the benefit of having delivery be a mostly fire-and-forget kind of thing. (caveat, it would be nice to have a mechanism for clients to know when a delivery failed…)