I’m not sure if ActivityPub allows for an extension like that. And I mean if you open up a separate direct channel via TURN… It’ll be incompatible with something like Mastodon anyways, so I then don’t see a good reason for why to bother with the additional overhead of AP in the first place. I mean you could then just send the status updates in some efficient binary representation as data packets directly do the other players. So why use ActivityPub that needs to encode that in some JSON, send it to your home instance, which handles it, puts it in the outbox, sends HTTP POST requests to the inboxes of your teammates where it then needs to be retrieved by them… In my eyes it’s just a very complicated and inefficient way of transferring the data and I really don’t see any benefits at all.

So instead of extending AP and wrapping the game state updates into AP messages, I’d just send them out directly and skip AP altogether. That probably reduces the program code needed to be written from like 20 pages to 2 and makes the data arrive nearly instantly.

I suppose I could imagine ActivityPub being part of other things in a game, though. Just not the core mechanics… For example it could do the account system. Or achievements or some collectibles which can then be commented and liked by other players.

Probably for European users if Europe decides to force gatekeeping platforms to implement such a feature.

Yeah, you’re not doing it right. On Github you have to click on “Insights”. And alike Lemmy which is split into two parts, llama.cpp also has a backend called ggml that does the (tensor) maths. Combined, the git stats are as following for the last four weeks:

• Lemmy (+UI) 207 files changed, +7,841 additions and -6,472 deletions
• llama.cpp (+ggml) 707 files changed, +157,754 additions and -95,611 deletions.

So they definitely touch a lot more code regularly. Whichever PRs you clicked on, they added 50 times as much new lines of code in the same timeframe. And coding things like that is maths heavy and you also need to read the scientific papers and implement the maths. And they did quite some maths themselves and contributed their quanitzation techniques and benchmarked and studied them in addition to the coding. I’m really impressed by the guy. And he seems nice and attracted quite some contributors with his excellent and fast software. Reviews and comments their ideas and integrates them fast. And now it’s a flourishing project that leads in its field. And the project isn’t even that old…

I get it. Software development isn’t that easy. Especially the ‘touching different parts of the code’ is something I don’t really like. I mean it is like it is. And having architectural patterns like this is fairly common (logic, database, UI) and you have like 2 models of the data, one for federation and then the internal representation. I’m not that familiar with the Rust frameworks and how cumbersome it is to deal with them. With the correct database abstraction toolkit and other frameworks it gets better and you can often tie the stuff together. Also helps with the bugs. If it’s really bad, maybe the architecture isn’t optimal. Or the chosen frameworks suck. Other than that it’s the job of a programmer to tie those aspects together, deal with the complexity and combine it into a working product.

I’m not even sure if you can assure that Lemmy has no bugs… I mean unit tests, integration tests and reviews won’t cut it with distributed or federated software, right? I mean you’d need to roll out a small cloud of instances and do end to end tests, check if everything federates and if there are performance regressions… I’m not sure where Lemmy is regarding this. I occasionally observe when something big happens like federation breaking.

Sure. And UI programming is also something that is not really fun to me. I’m also not sure why it hasn’t more contributors. Maybe the atmosphere isn’t that welcoming to new people. Or the userbase in total is just too small. I mean fediverse observer reports like 50k Lemmy users, and that’s not that much people if we’re talking about the subset of people who learned programming and have the spare time to contribute. Maybe it’s too interlinked with the rest of the code or not documented enough. I’d say it’s probably not that attractive to get involved because it’s mainly small bugfixes that can be implemented without also getting involved with the rest of the project. And apart from drive-by pull requests, people usually have some bigger vision when they join a project.

That makes more sense. Thanks.

I think it’s a bit of a chicken and egg problem if the revenue depends on the product. Lemmy needs to be shiny, grow and be attractive to attract more money. And they need more money to do it. Currently the userbase is stagnant at a bit less than 50k active users. I’m not sure if the community will jump in and provide the required amount of money if the situation stays as is.

Thanks. So the number on join-lemmy.org already includes the NLnet fund? I suppose that means you get ~600€ a month from the other (independent) supporters?

I’m confused. Liberapay 1.679$ + Patreon 1.165€ + OpenCollective 935$ + Crypo

adds up to the ~3.600€ but in which category are the NLnet bank transfers?

Kinda depends on productivity. I’d say 45k to 60k€ is alright for an average coding job in some company. I don’t know the details here. For self-employed people that varies a lot and developing Lemmy propapbly doesn’t compare to a salaried job at all.

Since I’m dabbling in AI at the moment: What about llama.cpp? Dude handles like 50 pull requests a week, coordinates everything and codes himself. And it’s really complicated stuff and not the only project. And I mean there is lots of Linux software I use, (web-development) frameworks, smarthome stuff and electronics projects that I participate in and I’m always fascinated by their pace and how they manage to do that in addition to a day-job?! And they regularly push new features… I’ve had contact with some, filed bugreports and sometimes the next day they solved my issues and pushed a new version.

With Lemmy, my UI bugreports from a year ago are still open and not fixed. And it feels like contributions and bugreports are more a burden to the devs here and not that welcome like I’m used to from other projects. And yeah, I’m glad the last release was a bit bigger. But I mean it took 5 months… And moderation tools are traditionally an issue here. I’m glad something gets implemented. But we’re still far from where we need to be. Same with the image handling and proxying.

I’m not sure what to make of this. Sure, software development ain’t easy. But every new release I check the changelog and usually it’s just some minor bugfixes. And twice a year a bigger release like this month with new features, yet the last bigger user-facing feature I can remember was instance blocking in december. And this is more or less adding the ability to hide posts and change how voting is displayed, if you’re just a user.

Edit: I appreciate the work, though. And I like the idea of the platform. It’s just that I’d like it to grow and flourish. But to me it seems we’re often taking baby steps. And in the meantime stuff breaks and admins complain they barely cope with everything with the tools they have.

I’m not sure about the numbers but it should be like 6,600€ a month?! join-lemmy.org shows 3,656€ per month from donations, plus ~750€ a week they said in their last AMA from the NLnet fund.

I’m not sure if I’d consider that low… Sure it’s not much compared to the revenue of a commercial platform. But still, you can build something with like 2x40h weeks. (plus a community)

Maybe they already factored in the 3k from NLnet and it’s just 3.6k in total, I don’t really know. But they’re always talking about two full-time developers plus one more they’d like to pay… So that makes me think it’s probably 6.5k€. Maybe someone can fact-check it.

AFAIK the NLnet funding is still running and there were still some milestones to claim as I last asked them in some AMA. Should be paying them an additional 3.000€ a month?!

They really should be more transparent an link that stuff and their progress.

https://lemmy.ml/post/11023519

https://codimd.tyhou12.xyz/s/TukD_H96z#

Though Lemmy has funding for full-time developers.

And it’s not like other features get implemented in the meantime. Progress is really slow here, even compared to hobby projects.

Edit: Lol, thanks for downvoting.

Hmmh. Why ActivityPub? I mean I suppose it’s alright as a standard for some turn based or slow trading game. But it’s neither very efficient nor suited for realtime. And having long (and descriptive) JSON messages, queues, … is baked in per design.

And it’s not even interesting to a Mastodon user if player x sold y latinum to player z. So for lots of game logic we don’t need messages in a common format that’s federated to Mastodon, Lemmy, Peertube etc.

I think a nice and not too complicated coding challenge would be to design a world that spans multiple servers. Players could roam a world, go through some door or portal and the client seamlessly connects to the next server. So that part of the world (the other server instance) is behind that portal. That’d make sense from an in-game perspective and won’t be that hard to implement. Basically it’s just like any other game, just that the client auto-connects to servers with some internal logic and not just in the start menu. And ideally authentication would be federated. The new server could ask the player’s home instance to authenticate them on entering the new instance.

deleted by creator

I think you’re doing it wrong. There are lots of people on Mastodon.

Hmm, I get you. But I don’t think that’s what this discussion is about. I’m more concerned with the technical difficulties / impossibilities / inconsistencies with the approach. Less so if it should replace the current solution or a possible upgrade path. That’s something to worry about later. It’s more like I don’t think it’s going to work properly. It’s more combining the disadvantages of two different approaches.

But I’m happy if someone goes ahead and does a better approach. I also see the shortcomings of the current solution. Maybe I’m being too pessimistic.

I really agree with your premise. Less responsibility on the server means less depending on it. We’d gain independence, could move accounts and do some more nuanced things. But I really think the less your own server or relay does, the more you’re prone to suffer from network outages, other servers becoming unavailable etc. So you’d need to duplicate everything no matter what to compensate for that. And you introduce lots of additional traffic by fetching all the hashtags from everywhere. Or you’d end up in the same situation as before where they’re subject of availability on your instance or perspective on the network.

Plus you want unsubscribed old posts showing up and a perspective that’s independant of the chosen instance. So you basically need to replicate everything everywhere. And this introduces additional complexity and resource usage and your goal was to reduce that. (And federation becomes just an inconvenience and additional unnecessary work at that point.)

It’s not that it’s technically difficult. We could do that. And you’re right by pointing at XMPP and Movim and stuff. But that also doesn’t solve most of the issues you outlined in your initial post. It’s even more narrow in how you rely on your own server and shaping your perspective on the whole network.

And sometimes this is what we want. People do dedicated instances to a topic. For example a Mastodon server for IT and tech people. Of course you want IT related stuff to show up on your main page. And we sometimes want moderation and a place to have civilized discussions. Not a place of anarchy and shitposting like on 4chan. That requires some form of hierarchy or democracy. And at the end of the day the server operators are responsible for what content is shared (publicly) via their infrastructure…

So I’d say you can’t achieve all your goals with ActivityPub. You need to think bigger. Maybe do away with federation altogether. Since federation is all about having different instances with a different focus and perspective on the same network. Maybe focused on a language or subject or sub-community of users, different rules and moderation. And you want more a unified perspective, everyone gets the same and less intermediaries. I’d say that is fundamentally incompatible with this form of federation and kind of out of scope. You probably want a network without that hierarchy. And that comes with different technical challenges and advantages.

(And suppose we extended ActivityPub. Instead of separating and moving stuff to the client, we could imagine you install a Lemmy or Mastodon server/instance on your computer or phone. Along your browser. You’d have it all on your device and could configure it like you wanted. I’m not sure if that’d be a superior solution.)

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.

Hmmh. But how would that then change Mastodon not displaying previous (uncached) posts? Or queries running through the server with it’s perspective?

And I fail to grasp how hashtags and the Lemmy voting system is related to a client/server architecture… You could just implement a custom voting metric on the server. Sure you can also implement that five times in all the different apps. But you’d end up with the same functionality regardless of where you do the maths.

And if people are subscribed to like 50 different communities or watch the ‘All’ feed, there is a constant flow of ActivityPub messages all day long. Either you keep the phone running all day to handle that. Or you do away with any notification functionality. And replicating the database to the device either forces you to drain the battery all day, or you just sync when the user opens the App. But opening Lemmy and it takes a minute to sync the database before new posts appear, also isn’t a great user experience.

I’d say we need nomadic identity, more customizability with the options like hashtags, filters and voting. Dynamic caching because as of now Fediverse servers regularly get overwhelmed if a high profile person with lots if followers posts an image. But most of that needs to be handled by servers. Or we do a full-on P2P approach like with Nostr or other decentralized services. Or edge-computing.

I don’t quite get where in between federated and decentralized (as in p2p) your approach would be. And if it’d inherit the drawbacks of both worlds or combine the individual advantages.

And ActivityPub isn’t exactly an efficient protocol and neither are the server implementations. I think we could do way better with a more optimized, still federated protocol. Same with Matrix. That also provides me with a similar functinality my old XMPP server had, just with >10x the resource usage. And both are federated.

Because with all of that, messaging, email, xmpp, matrix and ActivityPub most of the magic happens on the server. Take email for example. The server takes care to be online 24/7. It provides like 5GB of storage for your inbox that you can access from everywhere. It filters messages and does database stuff so you can habe full text search. Same with messaging. Your server coordinates with like 200 other servers so messages from users from anywhere get forwarded to you. It keeps everything in sync. Caches images so they’re available immediately.

That allows for the clients/Apps to be very simplistic. It just needs to maintain one connection to your server and ask if there’s anything new every now and then. Or query new data/content. Everything else is already taken care for by the server.

OP’s suggestion is to change that. Move logic into the client/App. But it’s not super easy. If you now need to be concerned on the client with maintaining the 200 connections at all times instead of just 1 to see if anyone replied… Your phone might drain 200 times as much battery. And requiring the phone to be reachable also comes with a severe penalty. Phones have elaborate mechanisms to save power and sleep most of the time. Any additional network activity requires the processor and the modem to stay active for longer periods of time. And apart from the screen thats one of the major things that draws power.

That’s a nice idea but has some pretty obvious technical drawbacks that aren’t discussed in the blog article:

The complexity of most networks grows about exponentially with the number of connections between the entities. It gets immensely more computationally expensive that way and you’re bound to use lots of additional network traffic and total cpu power that way.

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.

Other than that I like the general idea. The Fediverse should be more dynamic. Caching and discovery have some big issues in the current form. That should be tackled and we need technical solutions for that. And the current architecture isn’t perfect at all.

Furthermore, if talking about the edge where networks are smarter… Why then move it into the browser which isn’t at the edge? Wouldn’t that be an argument to invent edge-routers like in edge computing? I mean with c2s you have a server on the one side and a client on the other side with the edge somewhere in between. If you now flip it you end up in a different situation. But there’s still nothing at the edge where you could introduce some smarts…