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!

[–] h3ndrik@feddit.de 1 points 5 months ago* (last edited 5 months ago) (1 children)

Ah, you're right. Nostr uses relays. Now I know what the name stands for. Sounds a bit like your proposal in extreme. The "servers" get downgraded to relatively simple relays that just forward stuff. The magic happens completely(?) on the clients.

I'm still not sure about the application logic. Sure I also like the logic close to me (the user.) The current trend has been towards the opposite for quite some time. Sometimes the explanation is simple: If you do most things on the server, you retain control over what's happening. That's great for selling ads and controlling the platforms in general. On the other hand it also has some benefits for power efficiency on the devices. I'm not talking about computing stuff, but rather about something like Google Cloud Messaging which has the purpose of reducing the amount of open connections and power draw and combine everything into a single connection for push messages. In order to do decide when to wake a device, it has access to to the result of the filtering and message priorization. Which then needs to be done server-side.

I'm also not sure with the filtering of hashtags. I mean if you subscribe to a hashtag. Or want to count the sum to calculate a trend... Something needs to work through all the messages and filter/count them. Doesn't that mean you'd need all Mastodon's messages of the day on your device? I'm sure that's technically possible. Phones are fast little computers. And 4G/5G sometimes has good speed. But l'm not sure what kind of additional traffic you'd estimate. 50 Megabytes a day is 1.5GB for your monthly cellular data plan. A bit less because sometimes people are at home and use wifi... But then they also don't just use one platform, but have Matrix, Lemmy and Mastodon installed. And you can't just skip messages, you'd need to handle them all to calculate the correct number of upvotes and hashtag use. Even if the user doesn't open the app for a week.

I don't quite "feel it". But I also wouldn't rule out the possibility of something like a hybrid approach. Or some clever trickery to get around that for some of the things a social network is concerned with...

Or like something I'd attribute more to edge computing. The client makes all the decisions and tells the edge (router) exactly what algorithm to use to do the ranking, how to do the filtering and when it wants to be woken up... That device does the heavy lifting and caches stuff and forwards them in chunks as instructed by the client.

[–] rglullis 2 points 5 months ago* (last edited 5 months ago)

Doesn’t that mean you’d need all Mastodon’s messages of the day on your device?

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.