@design_RG

By the way I'd also like to point out one little piece of irony. Your "main" account over at muensterland. That account has been your "main" account for 5 months, prior to that qoto was your main account for about 6 months. Despite the fact that they were both your main for similar amounts of time, and you followed a similar number of people from each account... your account here at QOTO remains four times larger than your new main account.

@olamundo

@cy
Yup there is a reason we dont cave to their insanity. We do what is right in terms of server policy not what a few radicalized servers demand we do.
@design_RG @olamundo

@freemo @design_RG @olamundo Mostly I just wish people used public keys. Because we require a digital signature from the instance, not the user, it lets instances use their users as unwilling weapons to sabatoge other instances. I never thought I’d see it being done under benevolent pretenses, but here we are.

Maybe I should make a list of safe instances for people to join too…

@cy
Agreed, im all for personal control of our identity and keys
@design_RG @olamundo

@cy

> 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.

Very true -- that is one angle I hadn't thought about. In fact, the account deletion at the one instance, a huge Abuse of Power considering the circumstances (honestly and clearly documented in the blog post, linked above in a previous comment), that also meant a deletion of the user account content EVERYWHERE.

I have read and thought about the way Hubzilla does things, and it seems a lot better. There, we can pack up at move, with ALL our content preserved, intact.

Which is impossible in Mastodon. The only tool offered is a backup archive creation. This archive, with all toots, images etc, currently cannot be imported in any other instance; and there's no software to view it, to retrieve a toot's text or the attached media, etc.

Not only the @admin did this, surprising since their is supposed to be a Left wing instance, (which I am aligned with).

I had the displeasure to see a good friend lose completely his account and all data from mastodon.social - and no appeal was possible or got any results.

No abuse from this user either. We need smaller instances and closer control of our data, plus portability.

@Gargron

@freemo @olamundo

@design_RG
Importing toots is something ive wanted to add to qoyos feature list. This may be a good reason to focus on that.

I should also point out promising not to behave in this was is also what free speech instances are all about.

@cy @admin @Gargron @olamundo

@freemo

If someone could take a shot at creating a JSON viewer, with the proper intelligence to handle the mastodon exported archive, it would already be a HUGE improvement.

Currently, **there's no tool that I know of** -- and [I have posted **a detailed Blog on this**](https://write.tedomum.net/rgx/mastodon-options-for-moving-an-account), and asked friends in various instances.

Got a few pointers but the only viewer I could use was not intended for this and a bit cumbersome.

We are potentially looking at large amounts of personal data; **7000 plus toots, thousands of images in my 450 MB archive**, from this account here at Qoto.

Importing the data into a new instance has big difficulties as it will be propagating to other instances, etc. So this is a difficult and critical job.

**But an archive handler which can navigate the saved data would advance things a lot** and not pose this type of problem. We would be very grateful to anyone who took that project on.

@cy @Gargron @olamundo

@design_RG

Pretty printing JSON is easy if that's all you want. I guess it depends how far you take it though. If you want a pretty html interface and rendering of markdown in the toot contents and other bells and whistles it becomes a bit more involved, but doable.

Honestly in some ways it might be just as easy to build an importer than it would a viewer, again depending on the feature set of the viewer.

I've had several users in recent days particularly say they would want to mOVe to qoto if they could take their toots with them.

The issue I see with an importer is just one really, that is, a person could abuse it to create post-dated fake toots. The importer would effectively add the ability to create toots with any date timestamp you want.

The other issue is preserving the threads on the toots, this seems like it could be impossible.. Other users replied to your post at another account. You cant change their post to point to your copied toot at the new account. So while importing all your toplevel toots is doable you couldn't really do anything to effectively import the thread of replies attached to it. Even if you only imported your own replies to your own threads they would mostly be hanging replies since the parent comments would be missing.

Is bugzilla even ActivityPub? I would imagine the only way importable toots would be possible at all is if it didn't use the activity pub standard at all. In which case I'd wonder how they safely handle these concerns.

@cy @Gargron @olamundo

@cy @design_RG @freemo @olamundo
> we should be using public keys

Already the case, but stored and controlled by the server of course :P

Interesting vector. Who wants to client sign every post⸮
@lanodan @cy @freemo @thatbrickster

@461

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.

@lanodan @thatbrickster @cy

@freemo it implies something more fundamental:
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

@461 Using OpenKeyChain as the key provider, clients would have it easy in comparison.

@freemo @cy @lanodan

@thatbrickster You'd need to rework ActivityPub to accept that exchange then.
I don't think Eugene/James wants PKI.
@cy @freemo @lanodan

@461
>inb4 they suggest making it keybase compatible

@cy @freemo @lanodan

@thatbrickster

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.

@cy @461 @lanodan

@freemo because you need to sign a post to send the notice to another server.
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

@461

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.

@lanodan @thatbrickster @moth @cy

@freemo I'm not talking about the client, I'm talking about activitypub.
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

@461

In this example is A and B servers and x is the source users public key and y is the destination users public key?

@lanodan @thatbrickster @moth @cy

@freemo @461 @thatbrickster @moth @cy Aka: Consider putting better names on your variables you fucking mathematicians.

@lanodan I'm sorry junior, I'm really creatively thinking how to exploit this vector more than solving ActivityShit.
@freemo @cy @moth @thatbrickster

@freemo 'x' is the public keychain servers know and exchange with other, if not ActivityPub breaks. 'y' is your personal key you client side signed your post with. B(x) doesn't have your key, it never should, but server A(x) has to validate as it's own for B(x) to accept it, to federate it.
@lanodan @thatbrickster @moth @cy

@461

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.

@lanodan @thatbrickster @moth @cy

@freemo The raw part you're still not understanding:
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

@461

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.

@lanodan @thatbrickster @moth @cy

@461

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).

@lanodan @thatbrickster @cy

@461

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.

@lanodan @thatbrickster @cy

@461 @freemo @cy @lanodan @thatbrickster

Self signed? Couldn’t server issue per-device key sign by server?

@moth You mean like when new OAuth tokens get issued?

@461 @cy @freemo @lanodan

@461 @cy @freemo @thatbrickster As if ActivityPub doesn't already have a Client-to-Server API that almost transforms the server in basically just an object storage with federation.

@lanodan that's the dream, not the reality.
But I really really like this vector.
Ghost deletion seems extremely exploitable.
@cy @freemo @thatbrickster

@461 @cy @freemo @thatbrickster A protocol specification *is* a dream.

@lanodan @design_RG @freemo @olamundo Yes, that’s why I said “we” not “they.”