Followup: it appears that Pleroma is using
http://litepub.social/ns#oauthRegistrationEndpoint
so I’ll just go with that.
(OT: I updated FEDERATION.md url to point to Codeberg in AP implementers guide. Great that you keep it updated! Also posted earlier an idea to improve on the mechanism.)
One of the reasons of #software:openengiadina switching to XMPP is the lack of C2S support / impls. See quote from openEngiadina announcement on C2S:
It may be a good time to see if there’s progress made since this discussion petered out… the ones leading the pack without too many platform-specific concessions might be ‘standard bearers’, so to say. I am really curious about @macgirvin’s take. And also where @lanodan and @naturzukunft got since this discussion started.
The only client side implementation I found was andstatus, and it is unusable outside Mastodon or Pleroma as it relies on platform-specific and/or undocumented APIs to even establish a connection. I never got to the point where I could even test the server side of the C2S spec because that client wouldn’t even connect without all this non-standard baggage. Ironically openEngiadina’s abandoned(?) client effort might have been my best hope at moving forward; at least until somebody else gives it a go.
2 Likes
As written in the other thread i’m not part of the project where i was starting the AP C2S implementation ;-( And it’s not yet OpenSource ;-( ;-( i am curious to see if it will be available at some point in the future
The API of a dev system is accessable in the web: Swagger UI
you can create an oauth2 account here: https://dev-mdlk.digitale-doerfer.de/
1 Like
Thank you @macgirvin and @naturzukunft 
I noticed that @lanodan is keeping an ActivityPub Client-to-Server FAQ up-to-date and mentioning FedBox by @marius as possibly most-complete server, but no other clients mentioned. Did you go ahead with your client plans, @tonda? And there was a hackathon being planned Oct '20 with interest from @lain, @nightpool, @heluecht and @lanodan. Don’t know if that went ahead.
To be fair, all I require for testing is a script that will make an Oauth2 connection and send/receive arbitrary json payloads so that the server-side bits can be tested. The fact that this effort continues to drag on isn’t really due to technical reasons. Solving the problems of putting food on the table and keeping a roof over our heads in a disrupted economy continue to have a higher priority.
3 Likes
hopefully this is a typo 
if not, that’s exactly the problem in my opinion
The key term is arbitrary, as it includes not only the activitystreams profile of application/ld+json (from the ActivityPub specification), as well as application/activity+json (from the activitystreams specification).
In my case it also needs to be able to request and handle application/x-nomad+json as the nomad protocol is also built on top of ActivityStreams and a somewhat compatible C2S implementation of that protocol will likely be developed in parallel.
Since this client is providing a test platform for C2S it also should be able to request application/json, text/json and application/ld+json without a profile; the profile with and without https, and arbitrary whitespace and different quoting of the profile attribute — as we’ve seen every one of these variants in the wild within the fediverse.
So what’s the problem?
^ that is the problem
All my tests against AP implementations failed because of incompatibtilities of json-ld. that may be the problem of the json-ld parser i’m using, but my feeling is more the kind of json"-ld" that the AP implementations provide/expect.
This is beyond the scope of the topic. I’ll test my code against any form of garbage input I see fit to test against. Some of these tests should pass. Some should fail.
How you test your own code and deal with exceptions isn’t my concern.