@neil I mean, better than neither getting picked up, or only C2S, but

@ivan @neil Never claimed it was unreasonable, just claimed we could have an amazing future if projects implemented both ActivityPub's C2S and S2S... my suspicion is, if Mastodon picks up AP C2S, Mastodon is the current role model in the space, and other projects will pick it up as well. It could be huge.

For a long time I was told that refactoring for AP C2S wouldn't be easy, but I can't understand how it would be harder than supporting Micropub

@cwebber @neil @ivan there is no motivation to a project like Mastodon to adopt AP C2S, because a large part of the Mastodon proposition is the Mastodon “brand” story. Mastodon is a lifestyle, and adoption of AP C2S would dilute that perception.

@cwebber @neil I have said this before but the main reason C2S is not getting adopted is that is puts too much responsibility on client developers. They're no longer implementing features everyone expects from Mastodon. Some might find that cool and desireable, but apps are fragile and fragmented over different platforms. If you can't guarantee two people to be able to use the same set of features on Mastodon, that's bad UX.

@cwebber @neil Imagine, everything that sets Mastodon apart from Twitter, Facebook, even Pleroma and Misskey - but now it's the job of an Android developer. That's a lot of work, and then it needs to be duplicated on iOS, SailfishOS, Windows, Linux...

Meanwhile with Mastodon's own API, the features are defined by the API, and app developers need only wrap them on their platform of choice. An iOS and an Android user can get the same experience.

@Gargron @cwebber @neil

feature fragmentation is a concern that mostly killed xmpp (and was the motivation behind Moxie Marlinspike’s signal not being federated), so it’s good to hear that you’re thinking about reducing/avoiding the worst of it

@gargron @neil I don't understand what you're saying. That Mastodon's API enforces a specific user experience? If so, my questions would be:

- What stops a different Android app from delivering a different user experience using Mastodon's API
- What stops a different Android app from delivering a different user experience using Micropub, which is also set up to be fairly general?

@gargron @neil Is it partly that the dream of "you can use any client with any server" is a threat to Mastodon's branding? That may be true to some extent, but that sounds a bit weirdly like the same hesitance to adopt federation under those same grounds.

And any argument against that seems to apply to adopting Micropub, but now you have two disjoint developer experiences, whereas you could have one...

@cwebber @neil The value of adding Micropub is questionable but it's a single endpoint that only allows you to post and delete, that's a miniscule surface area.

@cwebber @neil A C2S-supporting server has essentially nothing to do except store payloads in a NoSQL dump and blindly forward them. I am sure it will take comparatively little time to throw that together, so why does Mastodon need to do it when anyone can? And if it turns out that it's better than Mastodon, Pleroma, Misskey, Pixelfed and PeerTube, then that's for the best?

@gargron @neil That's not necessarily true, since activities still have side effects... but it's true that you can get away with that more.

@gargron @neil I would expect that servers should reject activities they don't understand, simply because they can't properly process their side effects

@mmn Well are we talking about S2S or C2S?

Also I'd agree with that more for non-activity objects than for activities

@mmn @cwebber also fallback summary - that should be legible in a note like environment such as mastodon, where content may not be.

@cwebber
The Mastodon API supports and suggests a specific experience. It doesn't enforce that experience, but building a generic ActivityPub client that could display any AP activity without relating to a specific server's scope of capabilities isn't accessible to most developers

#CommonsPub is a pleroma fork using AP C2S. You'll see implementation specific AP clients next year, but generic AP clients won't be viable for awhile
@Gargron @neil@social.coop

@AceNovo @gargron It seems to me then that what's missing there is the "here's what features you can expect from this server" api endpoint we've talked about a few times in the abstract

@cwebber @AceNovo @Gargron I don't really understand how any of the arguements against AP C2S don't also apply to micropub C2S. Micropub has create and delete, but ALSO update, AND it can do all kinds of 'post types' - according to the *microformats 2* vocab (which is managed on a wiki by a small community, rather than a W3C Rec like AS2) - which still may not correspond with stuff a Mastodon server would expect.
AP clearly specifies how servers should federate incoming activities [ctd]

@cwebber @AceNovo @Gargron [ctd] (side effects) but Micropub uses a mismatched vocabulary AND doesn't specify how the server should handle these in an AP/Mastodon context. There would need to be some kind of mapping from Micropub terms to AP server behaviour, by which point you're just rewriting the AP spec with the microformats vocabulary which seems.. like a waste of effort when we wrote the AP spec already to do exactly this

@rhiaro @cwebber @AceNovo I'm not gonna implement Micropub

@Gargron
That is a shame. So we'll need to keep the mastodon API specific micropub bridges going then.

@cwebber @AceNovo @Gargron okay cool, got the impression someone was considering micropub over AP :)

@rhiaro @cwebber @AceNovo @Gargron

We have at least 2 independent implementations of micropub support with activitypub s2s (micro.blog and aaronpk.com ) that interoperate with mastodon - you used to have one yourself https://rhiaro.co.uk/2015/04/minimum-viable-micropub

@KevinMarks @cwebber @AceNovo @Gargron Not true that my implementation ever co-existed with AP S2S. Didn't say it was impossible, I said it repeats work the AP spec already covers, in a non-standardised way.

@cwebber
My first thought on building a generic client is that it would rely on the mime type and platform tools (mostly webkit) for rendering. Of course that doesn't mean every payload will rendered meaningfully, but S2S has been supplying an IRI fallback and that should mostly just work

That puts all of HTML5 inside the ActivityPub client. All we really want is some structured CRUD, so a consistent description of interfaces to prevent that outcome would be great

@mayel
@cwebber
OK, I misunderstood some of the discussion in the repos, then. The AP in CommonsPub is still S2S only. The client protocol is GraphQL, moodle_net in the repo. Kind of an "Aww, shucks," moment for me as I had spent some time consuming the spec

@lynn
The ongoing expansion of the Fediverse has been centered on different types of media, things that can be shared - nouns. Now, we've started growing around verbs - playing, learning, collaborating

So our representation of identity needs to grow, too. We've already outgrown the instance picker

@bhaugen @mayel @alexcastano @cwebber @Gargron

@bhaugen
Yes. I'll try to pick a simple one so it's easier to transfer to other domains

Pete plays Capt Varley of the Yamamoto in TBG, a space opera game on epicgames.club. He also controls a faction in a fantasy game. Enemies in one game may be allies in another and Pete doesn't need to log in to different profiles to control who knows him out of game
@Gargron @cwebber @alexcastano @mayel @lynn

@bhaugen @Gargron @cwebber @alexcastano @mayel @lynn
So a TBG player can @ Varley.Cpt.TBG or Yamamoto.ship.TBG to reach Pete, who can choose how he wants that handled. If Pete wants messages forwarded to his main, his reply will be routed through epicgames.club. In the process, addresses can be rewritten so the reply is apparently from the address used to contact him, which may be an alias, too

@bhaugen @Gargron @cwebber @alexcastano @mayel @lynn
That routing is a use CommonsPub should be able to serve that I don't believe was anticipated

More commonly you have groups with activity to the group shared to members according to a policy. That can be used for alliances, game forums, other scoped communications. Routing is just a delivery policy with a group of one

@bhaugen
I believe that aliases and forward secrecy are important safety features for some applications. The capability is implicit with collections and actors that aren't users, but making it explicit would help

Value flows are a rigorous form of deployment recipe, so my development needs differ from OCE mostly in robust abuse prevention being a more upfront priority
@lynn @mayel @alexcastano

@bhaugen
I'll test your noise reduction against my edgelords 😎

I have some reading to do. I've been looking for a concrete expression of a sharing economy to replace the exploitation and magical value creation present in most games. With any luck, my efforts may provide more value as a training resource than I consume with my curiosity
@alexcastano @mayel @lynn

@mayel GraphQL, imo, is a mistake. Using GraphQL over the existing ActivityPub C2S stuffs is just more complication. I can only think of one reason to use GraphQL and that's because the internal structure of Pleroma doesn't quite lend to C2S. But that's not the issue of the API. The biggest issue with GraphQL is flexibility. Did you know an object can have more than one attributedTo? Or even tag and attachment types that weren't even thought of? From what i can tell, this flexibility is a pain to implement in GraphQL. The easiest solution is imo to just use the C2S api as it is, like i do! (click here for the data i POSTed to my inbox) Also building your GraphQL implementation against Pleroma means you already lose a lot of finesse cause it uses an internal representation that is not quite ActivityPub, which i am pretty certain would be represented in the API.

@mayel s/inbox/outbox/, oops, and cc AceNovo as well

@puckipedia
The internal structure of pleroma is ActivityPub. My understanding is that the intent is to move complexity out of the client into the server. In the case of "attributed to," CommonsPub implements groups internally, so the client can reference the originators in a follow on activity without needing separate semantics depending on whether the original activity was attributed an individual or a group
@mayel

@puckipedia @mayel
The complexity cost of AP C2S could steer client developers away from strongly typed languages, resulting in an ecosystem where client functionality is adversely affected by the disadvantages of weakly typed languages wrt large projects. Worse, the entire client ecosystem could become wrappers for library x on platform y with little thought to interacting with content meaningfully

@mayel @AceNovo The internal structure of Pleroma can be considered a modified version of ActivityPub, but it is not exactly what is sent over the wire. And I am aware of the limitations of ActivityPub.

Kroeg is written in Rust, a statically typed language, and though it's slightly more verbose than it would be if everything was statically defined, it has handled literally everything anyone has thrown at it! Never mind that there's hardly any libraries to interact with GraphQL in Rust. Implementing a client that talks C2S is not that much work. Get the user ID, request its data, find the OAuth endpoint, rqeuest a token, use it to request more data. Moving stuff into the server means that you cannot really innovate clients. The primary function of the servers should be to relay messages, so clients can innovate independently of the server. example: Kroeg's Mastodon bridge is only loosely bound to the server, and can easily be used onto another proper c2s implementing server. of which there is currently one.

@tomas This is amazing. I put up my work as AGPL, promote ActivityPub and its other implementations, promote independent Mastodon apps, but if I dare have a personal vision for the kind of work I'm doing, I'm worse than facebook.