Did you read the next post on my series, by any chance? ;)
rglullis
joined 2 years ago
MODERATOR OF
connect to thousands of servers
So does a web browser. So does a mobile Lemmy client like Jerboa. "Connecting to thousands of servers" doesn't mean anything, if these connections are sporadic and uncorrelated.
But how would that then change Mastodon not displaying previous (uncached) posts?
You default to push (messages that come through the server), and you fall back to pull (the client accessing a remote server) when you (your client) is interested in fetching data that you never seen.
And I fail to grasp how hashtags and the Lemmy voting system is related to a client/server architecture
hashtags, sorting and ranking methods, moderation policies, and pretty much everything aside from the events themselves are just ways to visualize/filter/aggregate the data according to the user's preferences. But it turns out that this is only "complex" when your data set is too large (which is bound to happen when your server has to serve lots of users). If you filter the data set at the client, its size becomes manageable.
we do a full-on P2P approach like with Nostr
Nostr is not p2p, and p2p is not what I am talking about. Having logic at the client does not mean "p2p".
XMPP server (has less resource usage and is) federated.
Yes, because the XMPP server is only concerned with passing messages around!
What I am proposing is not getting rid of the server, just reducing the amount of functionality that depends on it. You won't be connecting with 200 different servers, you will still have only one single node responsible to get notifications.
Regarding storage: I can speak from experience that it you can have a local-first architecture for structured data that does not blow up the client. In a previous work, we built a messenger app where all client data was stored on PouchDB which could be synced via a "master" CouchDB. All client views would be built from the local data. Of course, media storage would go to the cloud, which means that the data itself was only highly-compressible text. You can go a looooong way with just a 1GB of storage, which is well within the limits of web storage
Also, perhaps if we learn to value servers, so not treat them as mere relays, perhaps we’ll be able to teach value and independence.
If you want to be independent, the only thing that matters is the ability to able to roam around and port our identity and data wherever we want. Where you are doing your computing doesn't really matter.
government schemes to repurpose old computers into mini servers and that governments should give everyone a domain like NAME.TOWN.CITY and everyone can run a personal server and get used to it and then they can grow from there.
We don't need any of that. Computing power and storage is so cheap nowadays that even people in middle-income areas can afford to collect piles of used smartphones on their desk drawers. If there was any type of economic demand for what you are saying, we would have seen by now some company trying to make a business out of it.
And some (a lot of) people like using social media on their phones instead of a computer. You’re bound to drain their batteries real fast by moving application logic there.
Messaging applications (that need to be online all the time) don't have this issue. Mobile email clients are even more conservative in resource usage. Why would an AP client be any different?
You are not going to be transcoding video or executing complex machine learning analysis on the device. I can reasonably argue that a local-first AcvitityPub application would be no different in resource usage than something like a modern XMPP or Matrix client.
Nostr is broken in one crucial aspect: your identity is derived from your private key. If your keys are compromised, your whole account is lost forever. WIth Actor Ids, your name can be a domain name, which makes it easier to protect your identity. With FEP-61 any DID could potentially be used.
I honestly don't like this "if you are criticizing what we have, it means that you don't belong here". You are responding like I haven't looked at Nostr, or even the other alternatives. It reeks of gate-keeping. But anyway, for the sake of argument: what I want is a mix of Libervia and Movim, with the ActivityPub vocabulary.
To me that's what a community is. Sharing and helping.
Too much of a good thing can still be bad. I made the same mistake with the alien.top bots.
If you think that posting about any reasonably important project is important, then fine. But then again, I'd reason that the people that share your belief would already be to the relevant RSS feeds, no? Maybe the whole thing that you are trying to do could be replaced with a "PSA" style post, where you link a OPML list of RSS feeds from the projects that are worth tracking?
Wait, why?
Are you saying that there is something wrong with all the communities you listed (to which I would also add !main@selfhosted.forum) ?
Are all the moderators against "believing into taking things into their own hands"?
It seems like yet-another community is just a manifestation of NIH syndrome. If you want to do it because you enjoy the exercise, fine. But then it makes little sense to also try to attract people that are already happy in other communities.
In the end, this seems like it does very little to help the ecosystem. Lemmy (and the Fediverse) in general is already struggling to keep people engaged, and this constant and unnecessary fragmentation makes everything worse.
I'd seriously ask you to reconsider this initiative. Let's strive to look for the best of things and keep united instead of sowing more division.
It looks like your cloudflared is trying to reach the Lemmy UI directly? What is the URL your tunnel is configured to reach?
You wouldn't need that. Think in terms of XMPP: a server could create the equivalent of a MUC room for tags, and the client could "follow" a tag by joining the room. The server would then push all messages it receives to that room. This scales quite well and still puts the client in control of the logic.
Similar architecture could be used for groups.