How to set up key-based identity in Mitra

Mitra implements a mechanism for migrating your connections from one server to another, which works even if your current server is offline. At the moment, this mechanism is only supported by Mitra. People who use different software won't be able to connect automatically to your new account, so the more of your contacts use #Mitra, the less connections you lose during migration. It's not very difficult for other developers to implement it though, and it's documented in FEP-7628 and FEP-c390.

For migration to work, two accounts must be linked to the same cryptographic key. To do that, you need to add a public key to your profile, then create a signature to prove the possession of the corresponding private key. You can think of this key as something that represents your primary identity and your fediverse accounts as temporary aliases. Mitra currently supports two signing tools: Minisign and Metamask.

Minisign

#Minisign is a command line tool. It might be difficult to use, but it is secure and doesn't violate your privacy.

1. Install Minisign. The tool is available in most Linux distros. For example, on Debian you can simply run apt install minisign.
2. Generate a key pair: minisign -G.
3. Go to your profile page, click on three dots to open the profile menu and select "Link minisign key".
4. Tell Minisign to export your public key:

minisign -R -f -p minisign.pub

Copy the text from minisign.pub file and paste it into the form. Press "Generate message" button.

5. Run displayed commands to create a signature. The first one (starting with printf) creates a file that needs to be signed. The second one

minisign -S -l -m message -x message.sig

creates a signature. Copy the text from message.sig file and paste it into the form. Press "Submit".

Now, back up your social graph. Go to "Settings" and scroll down to the "Export" section. Download both follows and followers lists.

Metamask

#Metamask is a browser extension and a cryptocurrency wallet. It leaks the hash of your public key to third parties, has non-free license and has other shortcomings.

However, it is much easier to use than Minisign. If you have it installed, just go to your profile page, open dropdown menu and select "Link ethereum address". Follow the instructions and approve the signature request. Done!

Migration

If you need to migrate your connections, repeat the linking procedure with your new account. Then go to "Settings", find the "Experiments" section with "Import follows" and "Move followers" buttons, and upload your previously backed up lists. That's all.

In the future more identity verification methods will be added. For example, a client may generate a private key for you, and let you back it up as a passphrase. This is less secure, because you have to trust the server admin to not steal your private key, but it is much easier than using Minisign. Arguably, the tradeoff is acceptable.

#Mitra v1.6.0

https://codeberg.org/silverpill/mitra/releases/tag/v1.6.0

- Enabled search by actor ID.
- Added "Export" section to settings page, where follows and followers lists can be downloaded.
- Improved Monero payment page, enabled automatic refresh.
- Added check-expired-invoice command.
- Allowed to connect to monero-wallet-rpc when it runs without --wallet-dir option.
- Account migrations (user-signed Move() activities). This is an experimental feature which currently is hidden in the UI. Based on FEP-8b32 and FEP-c390 protocol extensions.

#Mitra v1.5.0

https://codeberg.org/silverpill/mitra/releases/tag/v1.5.0

- Added Settings page with Change password form. This form can also be used to add a password if you registered with Ethereum wallet.
- Added CLI command that deletes empty remote profiles to free disk space. A remote profile is considered empty if it doesn't have any posts, reactions or follow relationships with local profiles.
- Using multibase encoding for integrity proofs, as required by the standard. This change breaks backwards compatibility, but shouldn't affect anyone because proofs are still experimental feature.

#Mitra can now process Move() activities.
This activity tells your followers to un-follow your old account and follow your new account when you're migrating from one instance to another. Mastodon can do that: https://docs.joinmastodon.org/user/moving/. I was unable to find any documentation or examples, and I've never seen this activity in the wild, so I just copied the logic from Pleroma.

The problem is that Move() activity must be signed by your old instance, and if the server is offline or if you're banned from it, there's no way to send it. To solve this problem, I want to let users sign activities with their own keys, so even if activity was sent from a new instance, it is still can be verified by other instances. There are two things that need to happen to make this possible:

- Embedded signatures. Mastodon can create them, but their implementation is not portable. There should be a clean and simple way to sign JSON object, otherwise embedded signatures will never be adopted in Fediverse.
- Identity proofs. This is a verifiable link between domain-based account and user's public key identity. Mitra already supports Ethereum identity proofs, and I'm planning to support GPG keys as well.

I've already started to work on signatures, and will create FEPs for each protocol extension (embedded signatures, identity proofs, user-signed move).

#Mitra v1.2.0

https://codeberg.org/silverpill/mitra/releases/tag/v1.2.0

- Added markdown parser to the backend. The client can specify content type when it creates the post: text/markdown or text/html. The latter type is still the default but support for it will likely be dropped in the future.
- Added support for object link microsyntax: [[url]]. The post may contain more than one link, but only the first link will be displayed as a quote on other instances. Example of such link: https://mitra.social/objects/0183de48-8756-9c31-65e8-c56369ac1abc
- Federation over Tor, I2P or Yggdrasil. I didn't test it, but it should work. This is not a multi-protocol federation: when your instance is onion instance, if can only federate with other onion instances. Multi-protocol federation is difficult to do and I'm not planning to work on it anytime soon. Instead, I decided to prioritize account portability in the next couple of months.