@neil I don't understand why Micropub would be considered when implementing ActivityPub's client to server stuff seems closer to the codebase Mastodon probably already has already
And the full power of ActivityPub comes out when *both* get implemented. I'm sad that S2S got massively picked up and C2S hasn't...
@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 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.
- 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 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?
@mmn Well are we talking about S2S or C2S?
Also I'd agree with that more for non-activity objects than for activities
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
@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
That is a shame. So we'll need to keep the mastodon API specific micropub bridges going then.
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
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
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
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
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
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
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.
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
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.
social.coop is a cooperatively-run corner of the Fediverse. The instance is democratically governed by its members, who generally share an interest in the co-op model, but topics of discussion range widely.
Our instance is supported by sliding scale contributions of $1-10/mo made via Open Collective. You must have an active Open Collective account to apply for membership; you may set one up here