h3ndrik

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.

You could also try the ROCm fork of KoboldCpp

Koboldcpp bundles an interface ontop of llamacpp. And generally it's relatively easy to get it running.

And cosmos-cloud.io too.

I think you mentioned the major ones. I don't think I'd give any of them perfect score. But I've had a look at most of them. And I've been using YunoHost for years.

I'd really like to have something that I can recommend to people, without any downsides. Maybe for small businesses, too. Or non-profits / clubs etc who need a mailinglist and a Nextcloud.

We probably need one super popular self-hosting solution. With SSO so it's simple to invite friends. Atomic / A/B updates so it's indistructible. Backups preconfigured and a Marketplace with 1-click installers. Backed by a non-profit or nice community and non-commercial.

As of now all advice here is kinda missing the point or wrong... (Exept the one recommendation to do updates ;-) I wouldn't use Cloudflare as it's really bad for freedom, watches your traffic and most interesting things aren't even in the free/cheap plans... You can't restrict connections to the "Established state" or you can't ever connect to your server... And SSH is a safe protocol. Just depends on the strength of your passwords... And yeah, opening ports is never 100% safe. Neither is using computers. They can be hacked but that's not helping... And I'd agree using Wireguard or Tailscale would help. But you already said you don't want a VPN...

I didn't have a proper look at the Forgejo Docker container. I'd say it's safe. It's probably using keys instead of passwords(?!) I hope they configured it properly if they ship it per default. And it's running sandboxed in your Docker container anyways and not running a system shell on the machine.

The issue with SSH is, there are lots of bots scanning the internet for SSH servers and testing passwords all day. Your server will be subject to a constant stream of brute-forcing attempts. Unless you take some precautions. Usually that's done by blocking attackers after some amount of failed login attempts. This is either preconfigured in your Docker container (you should check, or watch the logs.) Or you'd need to use something like fail2ban on top. Or ignore the additional load and have all your users use good passwords.

(What I do is use Git over https. That worked out of the box while ssh would have required additional work. But I also have lots of other ports forwarded to several services on my home-server. Including ssh. No VPN, no Cloudflare ... I have fail2ban and safe passwords. I'm happy with that.)

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

It depends on the exact specs of your old laptop. Especially the amount of RAM and VRAM on the graphics card. It's probably not enough to run any reasonably smart LLM aside from maybe Microsoft's small "phi" model.

So unless it's a gaming machine and has 6GB+ of VRAM, the graphics card will probably not help at all. Without, it's going to be slow. I recommend projects that are based on llama.cpp or use it as a backend, for that kind of computers. It's the best/fastest way to do inference on slow computers and CPUs.

Furthermore you could use online-services or rent a cloud computer with a beefy graphics card by the hour (or minute.)

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.