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

@cwebber @neil Mastodon API doesn't seem *horribly* unreasonable, though.

@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 @Gargron

federation is different. in the beginning, Mastodon needed OStatus / ActivityPub compatibility to tap into pre-existing userbases. after all, nobody wants to use a platform where there's only a handful of users.

the resurgence of GNU Social is a strong reason why Pleroma targeted OStatus instead of Diaspora protocol as the initial federation protocol supported.

@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

I think servers should accept avtivities they don't understand but save the fallback <content> .]

@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

I agree with @Gargron about ActivityPub Client-to-Server API putting a lot of work onto the front-end, but at the same time that would allow more functionality (especially to do with supporting other types of activities and objects) and innovation to be focused on the client side, which would make identity a bit less messy (people could follow me once and get my toots, video, photos, etc, and vice versa, I could have one unified timeline mixing different kinds of content). The answer to "what's a good alternative to Facebook" isn't one platform like Hubzilla, it's an ecosystem of truly interoperable apps. We've got the right tools, we just need to tie them together in useful and non-competitive ways.

A few of us are working on adapting the Client to Server API into a GraphQL schema, which I think will provide the best of both worlds, lots of flexibility for client apps while being easy to implement as the server can still to most of the ActivityPub/ActivityStreams heavy lifting.

Some of our immediate goals for #CommonsPub include:

- Federation that works for any type of activity, object, and field (including extensions). Side effects could be controlled by a sort of plug-in system similar to WordPress (including just bridging to an existing non-Elixir app's API). #MoodleNet will be a plug-in that extends #CommonsPub.

- GraphQL as the primary client API, with some generic very flexible and powerful (but complex) endpoints, and plug-ins being able to add endpoints to make things easier for their specific use case or client app.

- Support for Groups.

- Users can have several Actors. Actors can have relationships (and capabilities /permission) with each other.

- More kinds of Actors, including Group and Organization.

Some goals we don't have right now (put would accept merge requests for) :

- ActivityPub C2S API

- Mastodon API

- A server-powered no-JavaScript-needed basic HTML client, extensible by plugins

Forgot to @ you folks, always keen for feedback!

@AceNovo @Gargron
@cwebber
@alexcastano
@lynnfoster
@bhaugen
@ivan

@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

@AceNovo @cwebber

I'm trying to mirror the C2S spec in GraphQL as much as possible. It's work in progress, but will send you a link later.

@mayel

Love most of what you posted Mayel!

It is a challenge to use AP and still move to agent-centric communications in the fediverse. But I think it is important to do a minimum straight-up AP graphql api for the #commonspub C2S interface, so I'd like to try to get it to all mesh happily.

>"- Users can have several Actors. Actors can have relationships (and capabilities /permission) with each other. "

This is the one that I find possibly problematic. I think the goal should be for each person to have one Person actor for themselves, period. A Person can have many User (credentials) over time and for different methods of credentialing.

At the same time, people like to segregate the parts of their lives - so we would need a way to do that without creating more Persons. Adding something like Profile or Persona could solve that. Also, as Groups become supported and Persons can join Groups, that will become another way to scope conversations.

Here is a quick sketch of something that might work without changing AP, just extending it. Profile is a new actor type. A Person can have many Users. A Person can have many Profiles. Feedback welcome!

@bhaugen
@ivan
@alexcastano
@cwebber
@AceNovo
@Gargron

@lynn

> I think the goal should be for each person to have one Person actor for themselves, period.

That is what I want, too, but would you require that for everybody? Or would people who want be able to have more than one Person actor?

(I don't see how we could prevent them from doing so, just wanted to clarify because I have seen that question come up before...while it is difficult now, as several people have commented, to have the same identity in more than one ActivityPub app.)

@mayel @ivan @alexcastano @cwebber @AceNovo @Gargron

https://write.as/matt/identity-in-the-fediverse

@lynn @mayel @ivan @alexcastano @cwebber @AceNovo @Gargron

@bhaugen @mayel @ivan @alexcastano @cwebber @AceNovo @Gargron

>That is what I want, too, but would you require that for everybody? Or would people who want be able to have more than one Person actor?

No of course we can't (and I don't want to) require that. But to make it possible. If people want to manage their own several Person identities, that is fine. Thanks for noticing that.

@lynn
@bhaugen @ivan @alexcastano @cwebber @AceNovo @Gargron

I think that's the key, our backend will make that possible, but it doesn't mean that every (or any) app needs to make it available

@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

@AceNovo

Can you explain more of what you have in mind and if possible some ideas about how it might be implemented?

And maybe compare to what Mayel and Lynn are talking about?

@Gargron @cwebber @alexcastano @mayel @lynn

@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

@AceNovo

Thanks for the scenario and explanation.

I'll think about it and work thru the models that Mayel and Lynn are working on and respond with some kind of mashup if I can think of one or just some followup questions if I can't. Might take me a couple of days.

@lynn @mayel @alexcastano @cwebber @Gargron

@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

@AceNovo

We want a combination of social and economic networking, so most of the social network requirements will still apply, but we will also want lots of filtering and routing options because the working environments will want their essential information but not a lot of noise. So these are all good topics for discussion at this stage.

@alexcastano @mayel @lynn

@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

@AceNovo
> concrete expression of a sharing economy

I assume you mean a whole economy, but will these help?
https://learndeep.org/ - high school fablabs sharing materials and designs
or?
https://forum.openhardware.science/

Or do you want it to be a game at this stage? Could be a good game. Play it in the fediverse, maybe...

@lynn @mayel @alexcastano

@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.

@gargron Why even allow anything other than Eugen Approved™ Mastodon apps then? With this mindset we might as well go back to the old silo services

@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.

@gargron You're free to do whatever you want, but concern for client developers ring hollow considering having a non-standardized C2S protocol just for Mastodon creates extra work for all fediverse client developers, who must implement it on top of AP C2S and whatever OStatus uses