Notices by silverpill (silverpill@mitra.social), page 62

@marcua FEPs? They are just proposals, and may never become standards. I can only say that the first FEP-ef61 implementation may appear somewhere in the middle of 2024.

@marcua Secure Scuttlebutt also uses encryption: https://ssbc.github.io/docs/ssb/end-to-end-encryption.html

@marcua AFAIK atproto doesn't have private messages yet: https://github.com/bluesky-social/atproto/discussions/121. Some Nostr apps may have encryption, I'm not sure which ones.

I think our main source of inspiration should be Matrix, which is also federated and supports encryption for both direct messages and entire rooms.

@Hyolobrika A plugin needs to be written in a full programming language, but it can let user configure itself with declarative statements. With a plugin system, there can be many different modules, some are user-configurable, others are fully automatic.

@smallcircles @evan Thanks, I'm definitely going to watch it

@Hyolobrika @bougiewonderland Yes, this is a good idea. It could be related to "Plugins" item in my list. With a proper sandboxing (in theory provided by Wasm), user could be allowed to install a custom filtering plugin that will work on a server side.

@marcua I'm still working out the details, but here is what I think could cause migration pains:

- With FEP-ef61, one account can use multiple servers. But many existing projects are designed for one-to-one relationship, and in these cases a lot of internal refactoring might be required.
- It changes how moderation works, in particular instance blocks. I think instance blocks will remain effective, but will be less effective than today, and a lot of people may not like it.
- It changes privacy expectations, because messages are signed and can be forwarded without asking a permission from an originating instance. Many protective measures like authorized fetch and follower-only visibility will likely be weakened. I think encryption standards must be developed to offset this.

@greyarea Thank you, I will

@bougiewonderland No, blocks should not be disallowed, but there should be a way for people to talk to each other if they want to. Instance-level block is a very blunt tool, and it seems that people are forced to use it because they don't have proper tools (like reply controls and fine-grained permission system). So, I doubt that it really makes Mastodon great. There's a lot of criticism of pervasive instance blocks inside and outside of Fediverse, and at least two competing social networks, Bluesky and Nostr, have made freer communication one of their primary selling points.

I think the ability to use multiple instances simultaneously (aka nomadic identity) is a good middle ground: domains blocks are still working, but people can connect via different route if they want to.

@Kiloku This means connecting people who want to be connected. Blocking by domain is a useful tool, because setting up a new domain is costly, but there should be a way to circumvent it. For example, actors can be made portable and capable of sending messages from more than 1 instance.

@helge Yes, having test suites is very important. I'm generally wary of solutions involving earning ✅s because the author of a test suite gets to decide what is good and what is bad, but you have done a really good job with funfedidev and support tables. It looks neutral and unopinionated, as it should be.

@jupiter_rowland I'm aware of @mikedev 's work, and I hope we will be able to agree on a pure-ActivityPub nomadic identity solution. Interop with (streams) is my primary concern. Mastodon will likely be the last project to adopt nomadic identity, so I'm not particularly worried about it (although the solution must be simple enough to implement for all ActivityPub projects, including Mastodon, otherwise it won't take off).

The same can be said about other features provided by (streams) and its predecessors. Lots of good ideas there, which I hope will be eventually adopted by other projects.

@evan Thank you for your comments!

>End-to-end encryption. It's time to get on this; I don't think building on top of an incompatible stack is the way to go, though

I'm interested in MLS because it promises private group messaging. Your proposal is much simpler, and doesn't require any fancy cryptography, but since we have a blank slate (no legacy implementations), I think MLS is worth considering. That being said, I don't understand how it works yet, and it is possible that MLS will be too complicated for our purposes.

>Quote Announce. This comes down to recommending `content` in the `Announce` activity.

Yes, this representation is possible too, but non-supporting servers will process it as a boost, and I think it can't be used in replies. Today almost all projects that support "quote" feature use quoteUrl (and some adopted FEP-e232) because links doesn't have these downsides.

By the way, here is an excellent comparison of various approaches: https://socialhub.activitypub.rocks/t/disambiguating-various-interpretations-of-a-quote-feature-pre-fep/3426

>In general, I think you've got a lot of good ideas here. The ActivityPub fork idea is terrible, though.

No, I'm not advocating for a fork. If you are talking about https://github.com/steve-bate/activitypub-mincore - I see it as a profile, and I think it could be useful for new implementers who may not know where to start, or frustrated when their implementation doesn't federate with Mastodon.

@Zerglingman In addition to actors announcing local posts, I'd like to see actors announcing tagged posts, similar to what https://relay.fedi.buzz/ provides, but implemented natively

@iwojima The version of ActivityPub used in Fediverse heavily depends on servers being online and able to make HTTP requests to each other. FEP-ef61 removes this requirement, and will allow us to use any transport (including DTN). It's a relatively big change to the protocol, but I think there's no other way

@Zerglingman I don't want to switch to a different tool when I want to write a private message.

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

@Hyolobrika Thank you

@Hyolobrika Do they have a recording? I can't find one even though the page says "RECORDED"

Happy Gregorian new year from #Gemini 🚀