3 ms·
In general, mastodon servers (well behaved ones at least) are kind of vouching for the timestamps of all the messages they host. If a user transfers their acco
by jameshart 3y ago
In general, mastodon servers (well behaved ones at least) are kind of vouching for the timestamps of all the messages they host.
If a user transfers their account over, with an archive of posts, and uploads them to a server saying 'trust me, bro, I totally posted all this stuff last year'... they're dumping a bunch of posts into that server's feed whose timestamps can't be vouched for.
There might be mechanisms for a server to pull in the timestamps from the original host server, or to recognize the posts as having been streamed over previously... but uploading post archives is definitely a 'high trust' action for a server to take on behalf of a user.
- wmf 3y agoIs this an official rationale? People can't migrate data because someone might backdate a post?
- hnaccount_rng 3y agoWhich is one of the things Twitter is used as an authority for (e.g. hash dropping). And even having an option to do so removes this utility
- vidarh 3y agoAs long as the old server is up, the timestamps are readily available. In the exports, the posts are signed with the users private key. Either way, the new instance can validate what the original instance said about the posts, and put up a banner saying "migrated from...", "date according to ...". There are some edge cases to consider, such as how well various software will deal with an activity showing up on a url different to the one it was created at, but the date thing is largely a red herring.
- jameshart 3y ago> As long as the old server is up, the timestamps are readily available But among the scenarios we have to expect for users wanting to migrate an account from system A to system B in the fediverse are ones where the user’s departure from the original server is not amicable, or voluntary. And, yes, where the source server has just blown up and vanished.
- vidarh 3y agoHence why I went on to write: > In the exports, the posts are signed with the users private key. This refers to the full archives you can export from within Mastodon of your own activity. There is every reason to make it easier for people to have always-up-to-date backups of their data because the current process means people need to actively think about it. That is a valid concern (and it really annoys me that Mastodon does not include the post signatures in the JSON served up by the API too, which would make it far easier to keep an up-to-date archive; there's no real reason not to). But as long as* the user has an up to date export, and as long as the other instance has seen your public key before or can otherwise verify it with a truster party, the authenticity of that data can be verified. It's not ideal, but it's an option. Improving on this would also be easy, and I strongly think that once someone adds an import, the other side of that coin really is to push to ensure signatures for posts are included in the API output, and e.g. encourage apps to opt to let users keep a full copy of their signed posts (that part of the design of Bluesky is one I like) offline. I also do think that the Bluesky choice of ensuring the user has access to a recovery key is good, and would love to see something like that added for ActivityPub as well - with or without Mastodon core devs agreeing. It doesn't solve everything, and you'd still be limited until/unless major instances buy in, so, sure, it's possible and maybe even likely that there will be a time period when Bluesky does better than Mastodon on it. Then again once they turn on federation, that might well get Mastodon devs to take this more seriously.