There is a lot of back history involved. Some admins don't like the terms of service used at Qoto -- **specifically some quite Libertarian statements** on it which I personally have made motions to change.
In some other cases it's because this instance did not block some other instance which they found deplorable and a nest of iniquity, etc.
I have been out in Diplomatic missions in the past, but not much resulted -- other than me sending detailed correspondence and sometimes being :
* told to not contact them again.
* or losing my local account at that instance for the attempt.
* or simply getting a polite rebuff on the attempt, which appears the most positive result.
#QOTO is **perceived negatively in some quarters** - and that has implications on **who sees your posts here as well**.
See these two blog posts for detailed info on some of my past attempts :
https://write.tedomum.net/rgx/when-you-discover-your-instance-is-blocked
https://write.tedomum.net/rgx/todon-nl-admin-reacts-to-polite-inquiries
>todon dot nl
Wait a minute! Why are you communicating with that user on gameliberty? It’s clearly a rightwinger or even alt-right.
>2 days later
Your account has been suspended and all of your toots and your uploaded media files have been irreversibly removed from this server and servers where you had followers.
They… that… they didn’t just delete his account. They impersonated him, spamming other instances with fake Delete messages, to trick them into helping retroactively censor him, regardless of their ToSes. Because he may have spoken with someone who was likely to be a wingnut.
…
THIS IS WHY WE SHOULD BE USING PUBLIC KEYS JESUS CHRIST
> we should be using public keys
Already the case, but stored and controlled by the server of course :P
🇳🇱
That question sounds like it implies it would take effort. Presumably if the client were written correctly it would just need to be be configured once and then every post would get signed automatically.
I don't think Eugene/James wants PKI.
@cy @freemo @lanodan
Mastodon is already keybase compatible (I suspect you may know that).. I use it myself. It has some limited use here in the sense that if your account is compromised you can revoke the verification of it. The problem is people cant retroactively figure out when that revocation took place so it can be hard to do forensics to figure out the point where messages were no longer officially associated with the person.
It's not your key validating your post, it's accepting the post signed by your key and server to pass on on the server that has to agree with that signature, not recognizing your key.
Eugene/James is responsible for his implementation of Mastodon, of which he refuses to completely verbatim the specs.
@moth I'm talking about federation.
@thatbrickster @cy @lanodan
Yea but a key signing something doesnt require manual user intervention if the client is written such as not to need it. So I'm not sure why thats a burden.
How do you send post A(x,y) to server B(x,?) if B(x) doesn't recognize your y key, but does validation A(x)'s key.
I'm not saying it's impossible, I'm just saying there's a lot of uplifting to do.
@lanodan @thatbrickster @moth @cy
In this example is A and B servers and x is the source users public key and y is the destination users public key?
@freemo @cy @moth @thatbrickster
@lanodan @thatbrickster @moth @cy
Im not even sure why the servers would even need to know about it at all to be honest.. let alone be a part of activity pub.. for example it could just call GPG whenever I try to make a post from my computer and ask it to sign the content of the post. The signature would just be attached as metadata. the usual server approach to signing would remain intact and uneffected.. When a client sees and gets your post if they too have the relevant feature then it would see the signature and verify it.
All this would manifest as some osrt of a check mark or other marking indicating when a post is signed and verified vs not. The signing process could therefore be completely automated.
There's nothing preventing external server C(x,B(x,g(y)) from deleting posts from B(x) and as it stands right now A(x). You need to rework ActivityPub to accept third party client side key signing so D(x,A(x)) can refuse C(x,B(x,g(y)) [false] deletion notices.
The case here is that A(x) exposed 'y' key compromising the chain world wide. You want to be able to register an account in server D(x) with your intact 'y' key so B(x) still accepts your new posts on the new server, after C(x) keeps trying force delete your posts forever.
@lanodan @thatbrickster @moth @cy
I'm not sure having a server delete your post is particularly an issue. Servers are not obligated to let your posts go through at all, a server might block you and could (and its perfectly acceptable to) drop your post. So posts just not getting dropped isnt an issue we are trying to solve here (unless im missing something).
the issue attempting to be solved is if a server spoofs another user. Kicked them off their account then uses their account to spoof messages as if from them. Thats what we are trying to address and the scenario i proposed I believe would accomplish just that.
As far as I know Eugene doesnt develop ActivityPub, he only consumes it. I think its Webber you'd have to talk about to isee if any such changes for AP is a possibility (probably not if it isnt backwards compatible I'd think).
Would it though? If the model allows for "anything" then presumably it includes the option (though not requirement) of personal key use. So not sure why the protocol would have to be reworked to **only** allow for that (or how it could be enforced as a standard even or what functional changes it might imply to do so)...
Its just thatfor servers that allow users to use their own key, and users that adopt it, then I can trust them. On servers where they dont do this or users dont employ it I would just trust those account's identity less so.
Self signed? Couldn’t server issue per-device key sign by server?
But I really really like this vector.
Ghost deletion seems extremely exploitable.
@cy @freemo @thatbrickster
ActivityPub would need to be reworked as a client-server model allowing self signed keys at registration and not whatever encryption the server & protocol decides.
@lanodan @thatbrickster @cy