Allow user override of server block & silence rules #7220
Comments
|
This is possible for "silence" blocks (although useless because silence blocks are already overridable just by following the user in question) and basically impossible for "suspend" blocks because suspend prevents Mastodon from making any record of data by that user at all in the database. So the only point of this feature would be if you had followers that you didn't want to follow that you still wanted to interact with and were only silenced, not suspended, on the new instance. Seeing as this feels like a pretty small usecase and that it would make an already-difficult-to-understand feature even more complicated, i'm not sure adding it is justified. |
|
Thanks for the information, like I said, I wasn't familiar with how much of this is implemented. Is possible to implement a client-side method of fetching posts from server "suspend" blocked servers, even if they don't exist in the instances db? Such as if I'm remote-following a user, manage those interactions with the server client-side such that the server admin is still able to prevent those "suspend" blocked servers from making records in the db? |
|
This would likely include some client-driven interaction with the "suspended" blocked server, so I'm sure there would be some auth that would have to take place if this is the case. |
|
That would require a deep restructuring of how mastodon fundamentally works and entirely new protocols. so, probably not. |
|
Is there an alternative way to achive this? With the ability to transfer accounts, the need for this feature is lessened, however with that pending I think this is worthwhile to persue from a usability perspective. |
|
Why would you need the ability to transfer accounts to do this? Make a new
account if you want to talk to new people.
More fundamentally, if you don't trust the admin of your instance to make
reasonable moderation decisions, then you shouldn't be using their server.
…On Sat, Apr 21, 2018 at 6:56 PM Matt Hamilton ***@***.***> wrote:
Is there an alternative way to achive this? With the ability to transfer
accounts, the need for this feature is lessened, however with that pending
I think this is worthwhile to persue from a usability perspective.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#7220 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAORV3KXIpPjYuG2IgTjoihD2c-5FesTks5tq7krgaJpZM4Teogu>
.
|
|
I dont really think its a good idea since users can make multiple accounts on any instance, the admins probably have their reasons for suspending |
|
This might be a duplicate of Give users the ability to unsilence users and instances for themselves #3890? |
|
@nightpool Right, exactly to my point. But until you can transfer accounts you have to create a new account. @Laurelai right. I'm not proposing that we remove the admins' ability to prevent select instances from making db interactions, that is a necessary feature and would remain unchanged. Additionally, if end-users have the ability to selectively un-block certain instances, it won't impact any other users on the server that have not overriden the sever's blocking of said instances. |
|
@Cassolotl Ah, I failed to see that one in my search (I was searching for things like "user", "block", etc.) That said, there's some reasonable discussion in relation to how that could/may be implemented and the technical implementations in this issue. If we close this issue, how should we continue the discussion in that thread? Should I copy/paste the description of the issue as a post in that thread? |
|
That's up to you! If I were in your shoes I would probably do something like that, if that helps. :) I'd copy over any good commentary that I thought hadn't been covered by other people already in that thread. |
|
@Eriner said:
There is not currently a means by which a client can authenticate with a remote instance, only the instance they're a client in the underlying protocols. Not yet, at least. @Eriner also said:
While there is some work being done on things which would enable remote authentication (though that's not the primary reason that work is being done), it probably wouldn't guarantee what you're trying to achieve. Simply because an instance admin is highly likely to control the entire server the instance is installed on and if they really want to they can just block all traffic from a remote instance at the firewall level. I guarantee that there is no setting in Mastodon (or any other web service) that can get past |
|
your comment is not strictly true with respect to the underlying protocols,
only mastodons implementation of them.
…On Sat, Apr 28, 2018, 10:13 PM Ben McGinnes ***@***.***> wrote:
@Eriner <https://github.com/Eriner> said:
This would likely include some client-driven interaction with the
"suspended" blocked server, so I'm sure there would be some auth that would
have to take place if this is the case.
There is not currently a means by which a client can authenticate with a
remote instance, only the instance they're a client in the underlying
protocols.
Not yet, at least.
@Eriner <https://github.com/Eriner> also said:
Is there an alternative way to achive this? With the ability to transfer
accounts, the need for this feature is lessened, however with that pending
I think this is worthwhile to persue from a usability perspective.
While there is some work being done on things which would enable remote
authentication (though that's *not* the primary reason that work is being
done), it probably wouldn't guarantee what you're trying to achieve. Simply
because an instance admin is highly likely to control the entire server the
instance is installed on and if they really want to they can just block all
traffic from a remote instance at the firewall level.
I guarantee that there is no setting in Mastodon (or any other web
service) that can get past pf.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7220 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAORVwYK0BcPI8457K2N_NNNwf2QHzliks5ttSHLgaJpZM4Teogu>
.
|
|
@nightpool said:
It is true of Activity Streams 2.0 (AS2) and ActivityPub (AP). Currently there is no method for identifying a user on another instance as being that user, all clients only interact directly with their servers and the servers interact with each other. The only authentication methods available to users are those established by their server. Plus the only way they can possibly prove ownership/identity independently is to export data from a server (including the PEM private key) which is dependent upon the server providing all the information requested without modification and still results in a situation where that server has a copy of the private key (which it generated in the first place). I haven't checked OStatus, though. Still, I was under the impression that OStatus has less features than AS2. My focus at the moment is just AS2 and AP because while their security definitions are minimal at best, their structure and design is clear enough to make designing the solution not too onerous. I'm sure because while I'm not a Mastodon dev, I am a crypto dev and I've been poring through the AS2 (both core and vocab) and AP specs for a while now. I've identified what's missing and worked out how to provide it as a protocol extension which provides the maximum benefit and flexibility as well as security as an optional extension to AS2 and AP. Anyway, I should get back to that protocol extension design instead of distracting myself with issues unearthed while checking the number of requests for features it will be able to deliver. 😉 |
|
@Hasimir you may have overlooked this page https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization currently if a client has the private key for their account, they can make a signed HTTP request to fetch old content. Kroeg implements this, for example. Mastodon does not give clients access to the private key for security reasons, but there's nothing in the underlying protocol preventing remote authentication. Now, it's true that remote authentication is not all you need to implement this, and like someone said on mastodon recently, there's basically no way for this issue to be implemented in any federated-not-distributed protocol. But saying activitypub can't support remote authentication just isn't true. |
|
I hadn't overlooked that actually. That's OAuth 2.0 for client-to-server authentication and PKI of what's essentially the TLS/SSL variety for server-to-server authentication or verification. Anyway, I never said it can't ever be done, just that the current protocols as defined don't provide for that. There are quite a number of features, including remote auth and remote verification of authorship which the current spec can't do. Doesn't mean it will never be available; it just means that someone familiar with a cryptographic protocol which can meet those needs and certain others of a similar class, and who is interested enough to do the work; writes and proposes an extension to the protocol. I think one of the other most requested crypto related things around here is for any form of end-to-end encryption method for PMs/DMs, for instance. There are numerous options for crypto protocols to meet that request, but very few of them can also be used for authorship verification and remote authentication. Start adding all the different things people want and you really start to narrow down which cryptographic systems can do all of it, and only one which leaves the control in the hands of end users and was designed for use with a message type format. On the plus side, though, the de facto reference implementation of that protocol is, nominally part of the GNU Project. On the other hand, there's only about two dozen members of the GnuPG Project globally. The chances of one wandering past and deciding to play with a federated social network long enough to peer under the hood and tweak things must be pretty slim … right? Unless, of course, there were some form of political issue(s) affecting freedom of expression and/or privacy which had attracted attention first. I mean what are the chances of that? 😉 |
|
okay, I guess i'm just very confused at this point. this conversation might be better continued over IRC or on an ActivityPub issue, since we've deviated very far from the topic at hand. |
|
Fair enough. I'll have to remember to pop back into freenode a bit later. |
|
activitypub discussion happens in #social on irc.w3.org |
Allow user override of server block & silence rules
Note: I will refer to blocks/silences as just "blocks" -- the concept is the same.
Problem
In lieu of users not being able to transfer their accounts to another server, if a user wants to see posts from a server blocked by their instance's admin they're forced to create another account on the blocked server or on a server with no blocklists.
It makes sense for server administrators to be able to create a curated blocklist on behalf of their users, however users may have friends on other servers or want to interact with users on servers blocked by the admin.
A Solution
Allow users to override the server's blocklist by providing a way to selectively disable the default (admin-controlled) blocklist items, like languages. These values default to the admin-set values, and new entries add items to the client's list. Also, allow users to add their own items to the blocklist so that, in addition to petitioning admins for a block, they can meanwhile block the server themselves.
Questions
Are there any "gotchas" with this that make this a technical impossibility? Handling of boosts, how blocking works, etc? I'm currently ignorant in the implementation details of mastodon.
master(If you're a user, don't worry about this).The text was updated successfully, but these errors were encountered: