Ok, you are right about peering, I tried to get more peers to be faster, but it isn’t necessary. I didn’t find anything about ActivityPub broadcasting, but if it’s true… so, yeah, having rpc p2p connection doesn’t make the whole system less federated. But still, usually crypto clients has lists of nodes (or api balancers) for faster handling.
Huh, so the problem is about just serving static assets? TBH, I think this problem should be mostly solved, especially for such minimalistic UI. Maybe some (free) CDN? Also UI can use any lemmy server for most of requests (e.g. fetched federated_servers fom a bootstrap node) and use “logged one” only for user actions. I think it isn’t a terrible difficult task for the current ui (it has it’s own backend).
I know what you mean, but all nodes are equal, they are fully participating (stay aside validators). I mean every every node handles every transaction and can be faster than another (it doesn’t matter due to validation scheme, but technically speaking all nodes handling every user action)
I think a amall hit of p2p can be useful. Maybe as an addition layer. I worked a lot with tendermint nodes (cryptocurrency) and i saw pretty effective solutions.
Yeah, and this post about how to use some (a lot of) servers that are doing nothing to participate in “pros” while the top 20 of servers are suffering from these cons.
As I said, there is no profit from empty instances. Of course, the federation itself is good and fail-proof in this way. But if nobody asks for this cache, it’s just an Internet Archive of a sort.
Please elaborate, how is “every instance is sharing in the traffic to browse the fediverse”. I didn’t find it nor in AP standards, nor in activitypub_federation lib docs. If there is some mechanisms of balancing inside the lemmy’s code, would you mind pointing it for me?
I thought about Svelte + Tauri. Desktop but with Web flexibility. It also allows adding other fediverse as plugins.