@thisismissem said in ActivityPub API Client Reputation:
> Client reputation isn't really something you can track and share in a decentralized network without introducing some centralisation.
I think that some centralisation is fine, as long as admins or even users can choose their reputation data provider. We do this with blocklists for instances already; there's no reason to think that client blocklists would need to be any different. They'd have to have the same caveats; a trusted provider, transparency in the process, etc.
> You'd also need moderation tools that can moderate clients in some sort of meaningful way — that's near impossible for dynamic client registration.
Agreed. The best I can think of is using the redirect_uri, but that's not really unique -- especially for command-line clients that use localhost!
I think the ticket you're working on for moderating OAuth clients for Mastodon is a really big deal. I think it'd be a similar issue for ActivityPub API clients.
> That's why we wrote the CIMD spec.
Yes! Using the same identifier for clients in a verifiable way is a big help in having a reputation for using on a single server or multiple servers.
> But OAuth security and trust models are complex and generally proprietary
I think you could get to some pretty useful metrics pretty quickly, though. Some good ones to use might be:
How many people on this server (or other servers) have authorized the client
What the average rating has been (but you need a way to rate clients!)
How many Flag activities have been submitted for this client (you need a way to report clients)
Reviews of the client (you need a way to write a review of a client)
That data could be local to the server, or could be shared from other trusted servers. A trusted intermediary like IFTAS could be helpful.