Conversation

Notices

1. silverpill (silverpill@mitra.social)'s status on Wednesday, 03-Jan-2024 06:05:39 JST silverpill

   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.

   •  likes this.
   • Machismo (zerglingman@freespeechextremist.com)'s status on Wednesday, 03-Jan-2024 06:05:38 JST Machismo

     in reply to
     @silverpill Why would you want e2ee on a tool for screaming into the void
   • Machismo (zerglingman@freespeechextremist.com)'s status on Wednesday, 03-Jan-2024 06:09:22 JST Machismo

     in reply to

     • Machismo
     @silverpill >- Discovery. Content discovery on small instances: relays, decentralized search.
     ???
     Pleroma go brrr?
     Also https://git.crlf.ninja/crlf/dex/
   • anonymous (anonymous@freespeechextremist.com)'s status on Wednesday, 03-Jan-2024 06:09:26 JST anonymous

     in reply to

     • Machismo

     @Zerglingman @silverpill eeee!

     Machismo likes this.
   • silverpill (silverpill@mitra.social)'s status on Wednesday, 03-Jan-2024 06:19:51 JST silverpill

     in reply to

     • Machismo

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

     Machismo likes this.
   • silverpill (silverpill@mitra.social)'s status on Wednesday, 03-Jan-2024 11:21:38 JST silverpill

     in reply to

     • Machismo

     @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

   • silverpill (silverpill@mitra.social)'s status on Wednesday, 03-Jan-2024 13:05:30 JST silverpill

     in reply to

     • Evan Prodromou

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

   • Evan Prodromou (evan@cosocial.ca)'s status on Wednesday, 03-Jan-2024 13:05:31 JST Evan Prodromou

     in reply to

     @silverpill

     I missed this one!

     - Groups. A good one! `Join`, `Leave`, `Invite`, `Accept`, `Reject` activities all help. We need to revive the `members` collection, which I think helps a lot towards getting private groups.

     One you didn't mention was addressable contact lists -- like Circles from Google+ or Aspects from Diaspora*. A really helpful way to segment your followers and share some things with family, others with colleagues from work, and others with your friends who like trains.

   • Evan Prodromou (evan@cosocial.ca)'s status on Wednesday, 03-Jan-2024 13:05:32 JST Evan Prodromou

     in reply to

     @silverpill

     - Reply management. Starting with the `replies` collection and working outward from there is probably the best way to go. I love a's idea of using `Add` and `Remove` activities (or `Approve` and `Reject` with a target) to share state with addressees. I think the `conversation` tree could be managed about the same way.

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

   • Evan Prodromou (evan@cosocial.ca)'s status on Wednesday, 03-Jan-2024 13:05:33 JST Evan Prodromou

     in reply to

     @silverpill I think you're covering a lot of territory. I'm in agreement about some of these:

     - Data portability. We started a task force for this in the Social CG. Definitely important!
     - 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. https://evanp.me/2023/05/19/end-to-end-encrypted-messages-over-activitypub/ is much more in line with existing AP work.
     - Quote Announce. This comes down to recommending `content` in the `Announce` activity.

     [...]

   • silverpill (silverpill@mitra.social)'s status on Wednesday, 03-Jan-2024 23:24:41 JST silverpill

     in reply to

     • Kiloku

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

   • Kiloku (kiloku@burnthis.town)'s status on Wednesday, 03-Jan-2024 23:24:42 JST Kiloku

     in reply to

     @silverpill
     > fighting indiscriminate instance-level blocks

     What does this mean? Preventing instances or users from blocking other instances?

   • silverpill (silverpill@mitra.social)'s status on Wednesday, 03-Jan-2024 23:41:13 JST silverpill

     in reply to

     • Celeste Ryder 🐾 🐀🏳️‍🌈

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

   • Celeste Ryder 🐾 🐀🏳️‍🌈 (bougiewonderland@freeradical.zone)'s status on Wednesday, 03-Jan-2024 23:41:14 JST Celeste Ryder 🐾 🐀🏳️‍🌈

     in reply to

     @silverpill “Improving connectivity means fighting indiscriminate instance-level blocks”

     Do you mean you’d prefer instances not be allowed to block whoever they want or anyone blocking any instance they want? Because of so, I’d have to strongly disagree. This feature is what makes Mastodon such a great place to be. Dogpiled by nazis and their admins don’t do anything about it? Block they go.

     Or maybe I’m misunderstanding?

   • silverpill (silverpill@mitra.social)'s status on Thursday, 04-Jan-2024 00:11:14 JST silverpill

     in reply to

     • Hyolobrika
     • Celeste Ryder 🐾 🐀🏳️‍🌈

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

   • Hyolobrika (hyolobrika@social.fbxl.net)'s status on Thursday, 04-Jan-2024 00:11:15 JST Hyolobrika

     in reply to

     • Hyolobrika
     • Celeste Ryder 🐾 🐀🏳️‍🌈
     I mean as a personal feature controlled by each user, not admins.
   • Hyolobrika (hyolobrika@social.fbxl.net)'s status on Thursday, 04-Jan-2024 00:11:16 JST Hyolobrika

     in reply to

     • Celeste Ryder 🐾 🐀🏳️‍🌈

     If fedi had programmable kill lists, you could do something like deny <bad instance> in hosts or deny <bad instances> subsetOf hosts, where “<bad instance(s)>” is/are the instance(s) you don’t want posts from, “hosts” is the list of instance domains a given post is published from or that an author uses (maybe separate “postSources” from “authorHosts”), and “deny” is short for “deny if [a condition is met]”.

   • silverpill (silverpill@mitra.social)'s status on Thursday, 04-Jan-2024 00:17:14 JST silverpill

     in reply to

     • smallcircles (Humanity Now 🕊)
     • Evan Prodromou

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

   • smallcircles (Humanity Now 🕊) (smallcircles@social.coop)'s status on Thursday, 04-Jan-2024 00:17:15 JST smallcircles (Humanity Now 🕊)

     in reply to

     • Evan Prodromou

     @silverpill @evan

     For your information: There was an interesting #CCC talk on #MLS, see:

     https://media.ccc.de/v/37c3-12064-rfc_9420_or_how_to_scale_end-to-end_encryption_with_messaging_layer_security

     Video also mentions it in context of further work in the #IETF MIMI working group at:

     https://datatracker.ietf.org/group/mimi/about/

   • Hyolobrika (hyolobrika@social.fbxl.net)'s status on Thursday, 04-Jan-2024 00:33:27 JST Hyolobrika

     in reply to

     • Celeste Ryder 🐾 🐀🏳️‍🌈
     Would they need to be written in a full programming language? Why not just a list of declarative statements with conditionals, executed in order? I'm not an expert on these things but I don't see how one could do anything malicious with that.
   • silverpill (silverpill@mitra.social)'s status on Thursday, 04-Jan-2024 00:33:27 JST silverpill

     in reply to

     • Hyolobrika

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

   • silverpill (silverpill@mitra.social)'s status on Sunday, 14-Jan-2024 06:51:05 JST silverpill

     in reply to

     • dsfgs

     @dsfgs I agree, this is an important direction of research, especially for services like PeerTube

     https://github.com/Chocobozzz/PeerTube/issues/5783

   • dsfgs@mastodon.sdf.org's status on Sunday, 14-Jan-2024 06:51:06 JST dsfgs

     in reply to

     @silverpill
     To us we see scalability as the big one.

     As fedi scales, it appears that the way media-delivery is centralised, we will just end up with a few big CDN and fedi will be centralised again. In mid-Sept we began talking about an idea we call #'GlutPlug, where entities that toot, boot or fave a media post can become servers of such media. Serving and fetching over I2P would protect the users. An integrity hash set provided by the main server would ensure that provided media is correct.