I am building out
apcore is a server framework that provides both an ActivityPub server and an OAuth2 server in one, with support for things like webfinger, NodeInfo2 (soon), http signatures, some basic ActivityPub handlers. It’s super hand-holdy. I’d like to propose a flow like the following to include in
apcore and welcome feedback.
Given: I am operating an
apcore app on Instance A; there is User B on an
apcore app on Instance B; User B has Data1, Data3, and Data4 that has federated to my Instance A:
- User B goes to Instance A
- User B clicks on a “federated data checkup” button (I don’t have a good name for this)
- This initiates the OAuth2 Authorization Code grant flow between Instance A and Instance B. Instance A redirects User B to Instance B, who logs into Instance B, and Instance A obtains an authorization code. In this case, an authorization code is given, but no scopes are granted. Instance A just knows Instance B said “User B is authorized to act as User B” for the current web session only (the only time the auth code is tied to the user).
- Now User B can do the following, until their session ends:
- Request Instance A to count/list all federated Activities and Objects where User B is the
- Request Instance A to delete some/all of the data counted/listed, but inform them that Instance A may still fetch and cache their content in the course of routine operations serving its users.
The benefits to User B:
- Never has to create an account on Instance A
- Does not grant Instance A any scoped powers
- Sees their data on other instances (digital right to know)
- Have the power to self-service (digital right to delete) their data cached on other instances.
a big can of worms
In addition to listing and deleting their cached data,
apcore could also let User B opt into an option that says:
- Never process my federated data. I understand Instance A can still process derivative content produced by others that references or contains my data (such as Announces). This requires Instance A to record me as opting in.
how is this different than blocks?
Blocking, muting, ignoring, or any other of these sorts of actions would, using the scenario above, be on Instance B. This focuses on a different problem (a user’s digital rights) and attempts to expand it to peer instances, so this would bring User B’s digital right to Instance A as well. However, there are similar end-result effects.
This is a path I’d like to go towards with
apcore if possible, so that all app developers that use it are encouraged to interoperate and respect user’s digital rights in this way.
I understand other federated software isn’t necessarily an oauth2 server and would require work to reach par on this.
Edit: Link to fediverse discussion: https://mastodon.technology/@cj/103121031059732294