The problem is that I want it to work as smoothly as a commercial chat service on a shoe string budget, on a Raspberry pi sipping 2W. That and the fact that I’m bloody minded enough to work on it until it does, beyond the point of sanity.

You’ve summed up the entire glory and insanity of this sub in two meager sentences. Compression is over 9000.

Your end goal, friend, is noble, and I don’t mean to discourage you or gatekeep. And yet I must strongly advise you to slow your horses before you squander what I’d call your “social capital”, i.e. the willingness of the people close to you to follow your recommendations and try out new things. If they find their user experience greatly lagging behind what they’re used to, not only will they return to the services they were using prior to your suggestion: they will also be less likely to listen to you in the future and meet alternatives with skepticism, if not hostility. (“I’ve tried it and all this other stuff doesn’t work…”)

Thus, you need to make sure that they have an excellent first experience with whatever you throw their way. As a tinkerer, tech enthusiast, privacy advocate, or whatever you want to call yourself, you’re likely willing to accept a great amount of jankiness, pain, and lack of feature parity because you feel you get something more valuable in return. But that is not how most people use computers. Most people do not care about privacy, digital independence or any of the things you may cherish; they want things to “just work”.

And, to put it brutally bluntly (sorry!),

Like I think I’d need tailscale and docker (still dont get what docker really is)

this part alone tells me your solution is unlikely to “just work” for them. These are some basic skills to have if you want to try and compete with a billion-Dollar company and the convenience it provides to your friends.

So, my advice is this: don’t aim for “perfect”, aim for “better”. And basically anything is better than using FB Messenger, Whatsapp, Discord or whatever they may be using. Either go for one of the large public Matrix nodes (Matrix.org is unlikely to go down any time soon…) or move your comms to Signal messenger. Both may not be fully under your control (Signal is centralised, and Matrix nodes might be closed or defederated), but they’re e2ee and so professionally managed that your friends might actually enjoy them, use them on a day-to-day basis, and even pull other people over. That way, you’re also building social capital, so that once you’ve obtained the skill to run your own and get it to the level of polish it needs to have, they’ll be willing to follow you there too.

(If this posting sounds like I’ve learnt this the hard way, that’s because I have. Things are fine now, though: almost my entire social graph is reachable via Signal, and I’m preparing to self-host my own comms.)

Like the others have already said, it’s only an outage and it will return.

That said, what we’re seeing is precisely what privacy and software freedom advocates have been warning of for years now: the world’s overreliance on the centralised, proprietary infrastructure of a handful of US-based oligopolies have made people, companies and entire nations heavily dependent and vulnerable to blackmail, espionage and other forms of exploitation. Everything ugly we’re seeing out there, from the enshittification of services to mass surveillance, from the digital dispossession of users to the exploitation of software for political leverage, is a direct function of this overreliance. And it’s about time to break this cycle.

The alternatives and solutions are out there. Use the energy of your anger to make the switch; it’s going to bear fruit quickly! The go-to subs for digital independence are /c/[email protected], /c/[email protected], /c/[email protected] and /c/[email protected].

Google says it will not allow any apps in the Play Store to live stream video to social media from the glasses (not even YouTube live is supported). […] Real-time facial recognition is also off the table, according to Google.

For now. Then, when this privacy theatre has led to a less-than-Google-glass-terrible adoption of Gen 1, it’ll come as a “big feature upgrade” with Gen 2.

On the user privacy side, Google says it will not save any images or videos captured by the glasses in your Gemini history. Additionally, none of that data will be used for training AI models or targeting ads.

Mind you, this is coming from the company which, along with many other such violations, has tracked people’s locations regardless of their “privacy” settings.

Fuck this company. Fuck this product. And fuck anyone who buys this shit.

Came for this, left satisfied.

but if message are not encrypted during transit it’s bad.

I did not say that. ;) If you’ve secured your connection via SSL (which Nextcloud AIO forces you to do anyway), messages are encrypted in transit.

I said they’re not end-to-end encrypted, i.e. they’re stored on the server without encryption. To be fair, in theory, this is less of an issue if you’re the one hosting the service.

Strangely, on complain I received about signal was that they found it hard to save the pictures and videos shared on it

That is somewhat true. Messengers like Telegram (yuck!) and (correct me if I’m wrong!) even Meta’s Whatsapp (doubleyuck!) do or at least can store all media unencrypted on the device in a folder. Signal does not do this. Every single pic/vid/whatever needs to explicitly be stored in device memory in encrypted form (there’s even a nag screen every time you do this). Also Signal does no appear to have an option so it will store media in encrypted format to the device storage. (Just looked, didn’t find anything of that kind.)

With nextcloud talk, I would expect all the shared files to be available on the cloud drive.

That might be correct. When you install it, Talk stubbornly creates a “Talk” folder in your NC files, which is likely to hold all media shared via Talk.

[x] Doubt

It’s a nice story to tell, but this is definitely not the result of the prompt: “Recreate Pong”.

I have also tried to set that up. However:

• it’s not e2ee. Encryption is “experimental” for now, and didn’t work for me.
• it also requires a TURN server for cross-network calls and had some very weird issues on my degoogled devices (i.e. no notifications for messages or incoming calls).

That’s why I ditched it for now.

I would recommend that you use what the people around you use

That’s not what I have in mind. I’m playing trailblazer here: at least for the people closest to me, I want an alternative means of communication that will be ready in a minor shit-hits-the-fan scenario (i.e. one where Signal for instance goes tits up, like it already has once).

I’ve come across it, and I love the concept of making communication even more robust by making it independent even of the infrastructure of the internet. That said, I assumed that it would come with a lot more friction than the userbase I have in mind would tolerate. For now, my plan is to first seek an equally accessible, yet more decentralised alternative to Signal, and reserve digging into mesh networks for later.

Any recommendations?

Thank you so much for your offer! I’ve actually set it up last night and it’s running fine so far. It’s just that it won’t relay any calls if either of the devices is not on my network. Tunneling back into the network via VPN might be an option, but make it more cumbersome to use for some of the less techy folks around me.

What’s your primary reason to self-host Synapse? And who do you use it with?

Parents are liable for the actions of their children to a certain age.

First off, a technicality: At least in the jurisdictions I’m familiar with, “parents are liable for the actions of their children” is a popular misconception. The full story is: Parents are liable for the actions of their children only if it can be proven that they neglected their duty to supervise their children.

Also, I doubt AI companies would forego the chance to offload responsibility for their creations. Nothing in the article suggests they’d want AI to be treated like their children, but more like an entity separate from them.

Good luck! Feel free to ask if you hit a roadblock.

No. Put a Minecraft server inside the same compose file. Allow ICMP/ping, but firewall off all other kinds of access. Let it know it’s there, but it cannot play. Let. It. Suffer.

HP WiFi network printer owner here. It sits on my main network, but I’ve assigned it a fixed network IP (based on its MAC) and cut off internet access in my router. That seemed enough for me. I’m open to comments why that isn’t true. ;)

Accurate, all of it. You’ve got it.

Two more (nice) things:

1. (Assuming a star-shaped setup with a server at the centre) If you happen to make changes on the phone and another client device simultaneously (meaning: there is a collision of versions, since both have changes to write), Syncthing normally creates a “conflicted copy”. Whenever you see these files, you know that some changes couldn’t be merged and need to manually untangle the changes. No biggy normally.
2. Syncthing does support versioning, meaning: Your server can store several versions of the same database file. That way, if you happen to accidentally delete some entries from your DB, you can revert back to an earlier copy of the file.

Since Syncthing and LocalSend were already mentioned - let’s throw in Warpinator:

• built by the Linux Mint team
• has had an (inofficial) Android client for a while now
• works well (although Syncthing is a lot more powerful and requires fewer clicks once it’s set up)

Great questions, all of them! No, there need not be any “master file” - but there can be. ;) Let me lay it out for you.

There are two possible models you can build with Syncthing:

• a star-shaped client-server structure places the server at the centre of the network. The server is the central authority that always holds the “master file”, i.e. the newest version of the file, and the clients receive it from there (or don’t, if they’re already up to date). This structure, mind you, does not require dedicated server hardware: if you, say, have a phone, a notebook and a desktop PC, you can also make your phone the “server”, i.e. the only device that is connected to all the others and that “serves” everyone the newest version of your password DB.
• a meshed peer-to-peer structure has no centre - just a number of clients that are connected to all other clients. In this network, whichever device has the “newest” version of the file is the device that distributes this newest copy to all connected peers.

Which model you go for depends on how many devices you’re planning to hook up. If you only need to keep two devices in sync (e.g. your phone and your notebook), the client-server structure would probably be overkill, and actually Syncthing is typically deployed in serverless peer-to-peer scenarios.

However, if you have a lot of devices to sync, it may be more efficient to go with the client-server setup. Example time to make this more transparent!

Let’s say you go with the p2p structure because you only have a phone and a notebook hooked up to Syncthing. You configure:

• on the phone: share a folder with the notebook!
• on the notebook: share a folder with the phone!

But now you want to add another device, e.g. a desktop PC. Now you need to

• add the PC to the phone, and add the share
• add the PC to the notebook, and add the share
• add the phone and the notebook to the PC, and add the share

Otherwise you end up with a partial mesh, i.e. not every device immediately writes its changes to all others.

If you now add a fourth device that also needs to receive the share, you already have to make changes on four devices. And so on and so on. The more devices you add, the more work you need to put in.

TL;DR:

Syncthing can work without a “master file”. It can do peer-to-peer shares and work without a server. However, the more devices you need to share to, the more efficient a star-shaped / server-like architecture will become. This, however, does not require dedicated server hardware; you just decide that one of the devices will fulfil the role of the server by hooking all client devices up to it.

One last, minor correction: Syncthing only lets you share folders, not files. So you’d create a “KeePass” folder, toss your DB in there and share the folder to the receiving devices.