an appeal to the fediverse regarding anti-abuse 

an appeal to the fediverse regarding anti-abuse 

an appeal to the fediverse regarding anti-abuse 

an appeal to the fediverse regarding anti-abuse 

@emsenn @wilkie @cwebber Please elaborate on the autonomy of moderation point. What do you mean by that?

@Gargron If I understand it right - which I very well might not:

Current discussions of OCAP provide the tools to instance moderators, but don't provide similar tooling for users.

Right now, as I understand it, users can do most of the moderation action moderators can, relative to their own profile: they can autonomously moderate their profile even if their instance doesn't do moderation.

(Again, I could be wrong in understanding how things are or could be.)
@wilkie @cwebber

@emsenn @wilkie @cwebber I don't think that's quite right. Now, I don't know which "some of the solutions" Chris is talking about, because I'm aware of what I'm proposing (authorized fetch, same mechanism as already used for inbox deliveries) and what kaniini is proposing (OCAP), and I am under the impression that Chris's solution is OCAP too. But neither of those would affect any existing self-moderation mechanisms.

@Gargron
The issue isn't the UI for individual tools, but the effectiveness of such tools in an environment where the server administers keys and shares data without regard for scopes on the remote. Discovering scopes on the remote is a vector for targeted abuse. Individually authenticated access is a DoS risk. OCaps provide the benefits of authenticated fetch with a profile less conducive to DoS
@emsenn @wilkie @cwebber

Follow

@yaaps @emsenn @wilkie @cwebber DoS wise, if OCAP generates unique URLs (say, with a token query param), then it's just as uncacheable as authorized fetch, the difference being that a token needs to only be looked up against a local database, and authorized fetch sometimes needing to resolve a remote account through a synchronous HTTP request. However, in most cases only a database look up would be used, and we could also cheat and not do look-ups if the account isn't already known.

@yaaps @emsenn @wilkie @cwebber Regarding what the remote server does internally, I don't think OCAP is going to change anything significantly about that.

@yaaps @emsenn @wilkie @cwebber Let me correct myself: I think OCAP would help some behaviour rules be enforced when otherwise the state between servers is for some reason out of sync, as long as it's a good-willed server. But the point of attack that authorized fetch addresses aren't good-willed servers, but rouge actors.

@Gargron
Thanks

I'm making an argument from lesser to greater first. Even with only instance level effectiveness, the difference means being 2 hops instead of 3 from certain instances

The next step is whether you accept @cwebber's claim to provide a migration path from the current shared inbox to one where these scopes are possible. Worst case, abuses become an enforceable part of the social contact
@emsenn @wilkie l

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!