@trwnh@mastodon.social @kopper@not-brain.d.on-t.work valid points, but the spam concern is already true of AP as it currently exists. Actor keys can't be used to control spam since most of it comes from brand new accounts (or even dynamically-generated accounts).

All the backend software I've used (Misskey/forks, Mastodon/forks, and Akkoma) relies on domain-level and content-level restrictions for spam protection. User-level restrictions are good for other kinds of filtering, but not very effective against spam. Securing messages with an instance key wouldn't really change that.

@hazelnoot @kopper spam is always true of a default-allow policy, yeah. i was thinking of combining it with default-deny ("whitelist") or default-quarantine ("greylist") policies. tokens work better if you don't need to know who particularly is making the request. if the token starts getting abused, you revoke it. or you can expire it. etc

either way, the difference between user-level and instance-level is mostly in whether you expect the control to be handed to the user or the admin, which...

@hazelnoot @kopper ...depends on whether you care more about instance-instance connections or user-user connections. in other words, do you see the instance as a service peering with other services, or do you see the instance as a service provider for the user who makes their own connections.

right now, it's hard to separate these two views, because instances do so much. might as well have instances be actors that do everything on behalf of users (although i'd like a signal this is the case)

@trwnh @hazelnoot @kopper I think whether the *tokens* are instance or user level is fundamentally unimportant, what's important quite often is that the specific user is known. But you can have one token + a user metadata header

@erincandescent @hazelnoot @kopper only sometimes? like, if you want to authenticate a message came from who it claims to be attributed to, then yes you need identity. but if you want to know if a fetch is allowable, it would be much better to *not* know who is fetching, because that allows for tracking. it's the main reason we use proxy actors at the instance level for signed fetches

@erincandescent@akko.erincandescent.net @trwnh@mastodon.social @kopper@not-brain.d.on-t.work I was thinking token to authenticate the activity, and the actor property to authenticate the user.

@trwnh @hazelnoot @kopper and using proxy actors breaks fetches of private posts! Double edged sword!

@trwnh@mastodon.social @erincandescent@akko.erincandescent.net @kopper@not-brain.d.on-t.work for delivery, I mean. Fetch would just use the token.

@hazelnoot @erincandescent @kopper i kind of wonder if an "on behalf of" header or something would make sense for delivery. like in smtp the message might go through other services instead of being delivered directly. (in the current signature case this matters less bc the instance has your privkeys and can directly sign all http messages)

@erincandescent @hazelnoot @kopper i can't remember if mastodon ever fully implemented their strat where when a user searches for a url, they try fetching it as the proxy actor, then if that fails they try a second time with the user actor