use cryptography, for decentralized identities and content addressability.
the “fediverse” is ostensibly decentralized but that actually just means it has more single points of failure than the centralized model it is attempting to replace. (a failure doesn’t necessarily take the whole thing down, but, “federated” generally means there are more people and systems which could individually prevent information from flowing from point A to B; eg, I can’t message someone on another server if my server is down or if their server is down.)
Secure Scuttlebutt has a much better data model but is doing other things wrong so I haven’t used it much. Maybe Twitter’s Bluesky thing will produce something good, but I’m not holding my breath. What is clear is that ActivityPub is not a good long-term answer (but it is fun today).
Activitypub and Secure Scuttlebutt use entirely different technologies, and thus have different advantages and disadvantages. For now its just a fact that SSB has gained a lot less popularity, for inherent lack of user experience, in my opinion. Its just so much easier to create an account on a website, everyone online can do that. No need to install anything.
i don’t think most people are qualified enough to have serious ideas about protocol-level changes
I am by no means knowledgeable on the subject, so the suggestion might seems weird, but I would love it to be lass “arborescent” in its structure. I would love a single “child” item to have multiple “parents”. And that applies to :
User toward instances : a single user could be signed up in multiple instances that would mirror posts. As long as both instances allow it of course. That would allow to be present in multiple local timeline, and have some redundancy. That would also allow multiple peertube instances to host the same video, to help with the load when mutual seeding is missing.
Posts toward users. To allow multiple users to sign the same post would be great. It is to be quite different from a simple boost since there is no “OP”. Articles, music or even video can be made by multiple persons that don’t necessarily group up for a long time, so it does not justify the creation of a common identity like a music groups.
Combinaison of the two above : Post toward instances. A user belonging to two instances can either post to one, the other, or both. Then, this post is mirrored to both instances.
Comment/response toward post. This might seem weird. But being able make a single comment concerning multiple precedent posts can allow to make pertinent connection between subject and people.
In general, I think it is very difficult to think ahead about what uses people will find. So I think we should assume as little as possible and keep the uses as large as possible.
I would love it to be lass “arborescent” in its structure.
Reminds me of this post where I said :
The things we refer to as “threads” are actually “branches of a tree”. […] It would be useful if a discussion branch was not only shaped like a thread, but also had the usefulness of one : sewing, or tying together different discussion topics.
This post was about the “Comment/response toward post.”. I also like your "Posts toward users. ". Coauthoring is definitely valuable ! Relatedly, one could imagine a channel (like on Peertube) owned by several users. Then the channel could publish their common work.
Plume has this (for blogging). Also written in Rust.
All of that is possible with Activitypub. Its just that no one has implemented yet. Can you program?
No I can’t… But I should learn to, there is so much cool libre projects that I would like to help this way.
Pretty much the Zot protocol, but mainly build-in Nomadic Identity.
I dont think there is anything wrong with Activitypub. Some things need to be more specified (eg groups), but that will happen naturally over time as implementations converge. You just have to keep in mind what the protocol is, and what problems it can solve. Its basically a low-level protocol for communication between http servers, or essentially an api. Many of the problems that you think of in Activitypub are caused by specific implementations (mastodon), or lack of development/design. There are many more possibilities with Activitypub which havent been tried in practice.
Removed by mod
Performance is completely sufficient, i dont see any reason to try and optimize it. For a big instance, websocket will cause problems much earlier.
