@django

cc @mariusor

@django
>c2s
But why though? Basically nothing uses that besides an android app that probably hasn't been update in 5+ years.

@django Apparently AndStatus is still developed, so it is still used by something. That said the c2s interface in Pleroma was to be turned off by default I think due to lack of maintenance and recent security issues discovered in it.

@phnt I saw the issue. Do you know if it has been confirmed? (The timing is unfortunate)

@django There has been some talk about it around the 2.9.1 release months ago iirc, but nothing since. One of the Akkoma maintainers also disclosed recently some information disclosure issues that might affect c2s, so the subject might come up again. But if someone is willing to maintain it and fix issues, it will probably likely stay.

Not sure if Akkoma still has support for it enabled since they have a habit of removing features and options from BE.

@phnt I asked about C2S support in their issue queue, and they said they had more or less ripped everything C2S out of the codebase. The vulnerability was reported to Pleroma a few days later 🫤

@django Apparently the vulnerability is exactly what I found months ago and never investigated until two days ago

phnt@fluffytail.org fwiw some of us AP devs have identified that end user applications may not be the ideal (or even the only) use case for C2S.

A more interesting approach would be to pair it with OAuth2 authentication and use the C2S API as a transport layer in a server to server context. Performing actions on behalf of another user.

A more traditional API (e.g. Mastodon API) would be used to communicate with end user apps/sessions etc.

cc django@social.coop

@julian

Yeah a few of us had a good chat about that approach at the last #fediforum and we're now prototyping that in Bonfire at the moment, as a way to easily add federation capability to non-federated webapps (eg. for an events/calendar app to publish events by just POSTing a JSON with the event info via C2S to a bonfire server).

@phnt@fluffytail.org @django

mayel@sunbeam.city yessss! That's amazing to hear. NodeBB doesn't support the OAuth2 piece yet, but I am looking forward to getting started!

@django AP C2S has been disabled in Pleroma since 2.9.0, commit: https://git.pleroma.social/pleroma/pleroma/-/commit/d6a136f823c6e749e6d2c4a0f80202f0d7c5a960

Also I've noticed that it doesn't like Content-Type: activity/activity+json and can be quirky with cc/to so I'm not really a fan. I couldn't make a reply to a thread that would properly show up in FE. The parent was always not visible in the thread view, but visible when hovering over the "Replying to <user>" UI element. Probably something weird with addressing I'm missing.

@julian @django
>use the C2S API as a transport layer in a server to server context. Performing actions on behalf of another user.
Incredibly cursed and another case of "I can doesn't mean I should". I don't think that pretending to be a user should ever be done unless necessary (such as the case of automatic follow acceptance). Especially when it requires external authentication like OAuth2. At least with S2S you can use actor keys, but such concept does not exist in C2S. Not to mention that now none of the big ActivityPub server implementations support C2S (Mastodon, Pleroma, Misskey), so you are stuck in a bubble you are creating yourself.

Honestly, I would appreciate if the work that is being done to create toys around AP was instead focused on fixing the complete mess of a specification and making a v2 spec that isn't ambiguous and open-ended as a typical corporate privacy policy.

@phnt no me gusta, but it explains why it didn’t work on one instance I tested.