#Mitra v2.11.0

https://codeberg.org/silverpill/mitra/releases/tag/v2.11.0
https://codeberg.org/silverpill/mitra-web/releases/tag/v2.11.0

- Mentions can be limited in profile settings. Only two options are supported in this version: accept mentions from everybody and accept mentions only from known users. Known users include followers/following, and everyone else who was discovered by the server more than 1 hour ago. This may be effective against the spam from newly registered accounts, or may not - I haven't been able to test it.
- Federated timeline is visible to all local users

#Mitra v2.9.0

https://codeberg.org/silverpill/mitra/releases/tag/v2.9.0
https://codeberg.org/silverpill/mitra-web/releases/tag/v2.9.0

Highlights:

- Generating Ed25519 keys for all accounts (in preparation for FEP-8b32 activation).
- Send notification to admin when a new user is registered.
- Legacy identity proofs are greyed out on profile page and a small button is displayed that triggers re-verification. In the near future Mitra will stop accepting legacy identity proofs (FEP-c390 identity proofs were implemented in 1.28.0 / 2023-06-26).
- Added "Federated" timeline (aka TWKN). Currently visible only to admins.

FEP-ef61 updates:

- Replaced did:apkey with did:ap:key. With did:ap as a base, other similar DID methods can be constructed. For example did:ap:web can be used to delegate key management to a web service.
- Accordingly, resolver endpoint was changed from .well-known/apkey to .well-known/apresolver
- Added image attachment to object example. Objects have a signature that proves their authenticity, but attachments can't be verified in the same way. digestMultibase property solves this problem.

I also updated all related FEPs:

- FEP-8b32
- FEP-c390
- FEP-ae97

Fediverse tech roadmap

This is how I want our network to evolve in 2024. Some of the things listed here may have been implemented already by a small number of projects, but more work is required on standards and interoperability.

- Data portability. In my opinion, this is the most important problem. I'm in favor of FEP-ef61, which also solves identity portability and unlocks many new features.
- End-to-end encryption. MLS has become a standard, and it would be wise to adopt it. Issue 3 at fediverse-ideas provides a good overview of what we have at the moment (not much). Some variation of FEP-ae97 is likely needed to make end-to-end encryption work.
- Connectivity. Improving connectivity means fighting indiscriminate instance-level blocks, expanding to overlay networks (Tor, I2P and others), maybe also developing standards for bridges. In many ways, these tasks are linked to data portability.
- Moderation / spam resistance. Anything other than "list of instances I don't like" would be a huge improvement. Fediseer is an interesting development, but still leaves a lot to be desired. Additionally, standardization of reply controls is needed. FEP-5624 exists, but the mechanism described there has many flaws.
- Scalability. How to publish to 1M followers from a single-user instance running on cheap hardware? FEP-8b32 should make various optimizations possible (inbox forwarding, efficient reposts, etc).
- Plugins. Something like Pleroma MRF, but cross-platform (e.g. Wasm-based). Also, pluggable timeline algorithms.
- Discovery. Content discovery on small instances: relays and related standards, decentralized search.
- Developer experience. Documentation of de-facto standards (HTTP signatures, WebFinger). Simplified ActivityPub spec. Error reporting.
- Groups. We have several competing standards for groups: FEP-1b12, FEP-400e, Mastodon developers are working on their own standard. It would be nice to converge on a single standard, that also supports private groups.
- URL handlers. Again, competing standards: FediLinks, FEP-07d7 and several other proposals.
- Quoting. FEP-e232 is a proposed standard, but most fediverse applications still use non-standard properties. Mastodon developers are trying to invent something completely different.
- Synchronization of replies. Various approaches are being considered, but there's no clear winner.
- Markets. So far there's only one server implementation capable of processing payments. FEP-0837 (a protocol for federated marketplace) was designed, but lacking adoption.
- Forge federation. ForgeFed is being implemented in Forgejo, although the work is progressing very slowly.