@by_caballero @benpate @thisismissem @julian @naturzukunft that's too hard. We have an API. It already works.

@benpate @FenTiger @julian they should just pass them along! If you don't implement a side effect for that activity type, just leave it alone and pass it along to clients.

@benpate @FenTiger @julian the plan there is to have finer grained scopes for particular activities. And also limiting them by domain: "let this server Like and Reply to objects on its own domain"

Add more granular scopes specific to ActivityPub

fep - Fediverse Enhancement Proposals

Codeberg.org (codeberg.org)

@benpate @FenTiger @julian there's a whole chapter about the API in my book:

https://evanp.me/activitypub-book/

@benpate @FenTiger @julian also, and this is very important: if you want apps to have a global reputation, so that social pressure can keep them from being abusive, they need to have a universal id across different API servers.

evan@cosocial.ca I'm not certain whether it's too hard or not. At this point I haven't looked into it yet.

But if there is a chance that we can use standardized endpoints for this, then it's a point in their favour.

At the same time, I am a proponent of simplicity.

@evan @FenTiger @julian

This sounds perfectly reasonable, and is probably the right thing to do.

Except I probably implemented ActivityPub wrong - using it as a protocol and not an architecture.

Database tables represent the things I understand, and are written out as “JSON-LD” when needed. So there’s no true “outbox”, except as links to the tables I care about

Again, this is an “it’s me, not you” situation, but I’ll bet others might be in the same boat.

benpate@mastodon.social said:
> Database tables represent the things I understand, and are written out as “JSON-LD” when needed. So there’s no true “outbox”, except as links to the tables I care about

I am pretty sure 85-90% of the fediverse developers do this

The remaining 10-15% complain loudly when the "JSON-LD" we send back doesn't actually validate.

@julian

I honestly thought it was just me

@benpate @julian sure. But neither of you support the ActivityPub API yet, right? And you both have pretty good ideas of how to do this correctly and probably even easily in your software.

@benpate @julian I'm not saying it's absolutely necessary to support arbitrary activity types. But it makes sense if you want to support interesting innovation at the edge. Otherwise, sure, just support the dozen or so activity types defined in the AP spec, plus a few more from FEPs you know.

@benpate @thisismissem @julian @naturzukunft I forgot to ask: have you ever implemented an OAuth client before? Or used a library for it?

evan@cosocial.ca yeah, I implemented maybe 20-30 of them for NodeBB. Everything eventually standardized around OIDC and so I have one single plugin in NodeBB that works almost all of the time.

So that's my client, but I'm afraid of building a server. That one I haven't done successfully.

cc benpate@mastodon.social thisismissem@hachyderm.io

@julian @evan @benpate I've built 2-3 servers, but the good news is that you generally don't need to implement from scratch (unless you really want to, and then you take your time, reading the specs, checking other implementations, double checking the specifications)

@evan @julian

I’m confused, sorry. In this context, I’m assuming you mean the ActivityPub C2S API (which I have not implemented)

But I thought we were talking about a future update to the C2S API, which I think would be amazing, but I also haven’t implemented because.. it’s in the future?

I have done tons of OAuth clients and servers, and even have a Mastodon API about 80% complete.

benpate@mastodon.social I think the second half of evan@cosocial.ca's FEP utilizes the ActivityPub API (C2S) as written.