I’ve just looked at some tutorials for Keycloak and Authentik and there’s definitely a very steep learning curve for these two solutions. I feel like I need something a lot simpler to be able to fully grasp the concept.
What is the easiest solution for beginners to implement Sigle-Sign-On for their selfhosted services?
I’ve gone with Authentik for my homelab, and sure there is some learning to do, but it is fairly simple once it’s setup, and in the end it is not that bad.
If I were to choose over, I’d god with KeyCloak as it seems like that’s almost exclusively what’s used in the marked ~ and thus would be good to know in depth
Huh, nice.
What are my options for getting alerts on my android phone if services on my VPS becoming unresponsive?
My first thought is a simple app that periodically pings domains and gives a notification if any fail. Is there an open source app for that?
Or something else?
I haven’t touched my Oracle in months. What exactly is happening?
No idea. The dashboard says it’s running and fine, sometimes the shell console is ok, sometimes it’s also bogged down, but it’s completely non-responsive from outside. The other instance I have in the same tenancy but a different fault domain is perfectly fine, so I don’t know if that’s related somehow. I’m running Pangolin on it to forward a couple things, one of them is higher throughput than I had expected, but rebooting makes it come back, so I don’t think they’re throttling me.
I’m kind of at a loss, but I threw together a webhook to use their API to reboot it when it stops responding and that seems to be working while not actually addressing whatever the root cause is.
I’ve been struggling with something that sounds simple but is surprisingly annoying:
capturing content quickly across devices in a self-hosted environment.
On Android there’s share, on iOS shortcuts, on desktop copy/paste… but everything feels fragmented.
I often end up losing things or postponing them just because capturing isn’t frictionless.
Curious how others handle this.
That’s a really good way to frame it.
I kept coming back to the idea that the “act” shouldn’t be something new you have to learn — it should reuse what you’re already doing in each context.
So instead of one single physical gesture, it’s more like a single intent expressed through different native actions:
The key (for me) wasn’t forcing one gesture, but making all of those feel like the same action underneath.
So the mental model becomes: “this goes into my inbox”, regardless of how I triggered it.
That’s where things started to click for me.
Small update: DropMind just showed up in today’s selfh.st newsletter under development activity.
Feels like the idea is slowly starting to resonate — curious to see how people end up using it in their own setups.
That’s a cool idea! As others, I’m not too keen on using Telegram. Would it run with other messaging apps like Signal or Threema?
Interesting, didn’t know Telegram can have interactive UI for bots like this.
Does it exist, some sort of encrypted journal-like app where I can type things which will be forever locked away? In my mind and in a place I can feel confident about, without a doubt.
Pen and paper requires burning afterwards, I don’t think I want to do this.
I know no opsec solution is perfect. I need some sort of outlet. I need some sort of solution.
I was thinking. Maybe, at least, some solution where even though access is non-negotiable, if somebody does get in, I can accept that the entity was already determined enough to end things.
Thanks.
My first thought was pipe it to /dev/null but it sounds like you want it to linger for a bit before it goes into the shredder
Pipe it into /dev/null!
There’s also an online version from 1983: [Discard protocol](https://en.wikipedia.org/wiki/Discard_Protocol]
Hi!
I have noticed that when i run whois <domain> on some domains it returns a lot of information such as registrar name, abuse contact, creation date… but for other domains whois returns a paltry amount of information such as “Malformed request.” or just repeats the domain name and has “status: UNASSIGNABLE”.
HERE IS THE QUESTION: i want to buy a domain for the sole purpose of having a single A record that points to a corresponding PTR record on the VPS provider. however, i prefer to have the whois record be as minimal as the 2 examples i gave above. how are those whois entries so sparse? (the 2 domains in question are .it and a .fail top level domains.)
I am doing all this with the goal of hosting a tor node. any help is greatly appreciated! have a lovely day!
Cloudflare is free, I thought it was free everywhere.
Big same
Youlag is a FreshRSS extension that allows you to browse your YouTube and article RSS feeds through a modernized design that incorporates quality-of-life features.
It is designed for a distraction-free experience, for people who want to be intentional about their viewing habits.
Why?
Subscribe to creators via RSS without a Google account, stay free of algorithms, and access your subscriptions from any device. Youlag can also be used just for article reading.
Highlights v4.3.0
Other features
Find more details: https://github.com/civilblur/youlag
This looks great but unfortunately, it stops keyboard controls from working.
Youlag adds its own keyboard control, so it might be interfering with FreshRSS’ default ones. I personally never utilized any of FreshRSS’ keyboard shortcuts and might have overlooked that aspect.
If you don’t mind opening an issue in the repo with the relevant context, I might be able to look into it in the future.
Thanks for the suggestions on the router post I made a few weeks back! I think I’ll try to repurpose a no longer in use Mac Mini into being my OPNsense router on a VirtualBox VM! If that doesn’t work then I’ll consider buying one of the devices ya’ll mentioned in the last post.
But now I’m trying to look for an access point to flash Openwrt on and a managed switch to do my VLANs. I looked at supported devices on the Openwrt hardware list and looked them up on ebay and started saving some to my watchlist, and now I have a lot of sale offers that are gonna end in 1-2 days.
::: spoiler - Linksys Velop MX4200 (Tri-band, Mesh Wifi 6) - ebay link
Zyxel NWA110AX (Wifi 6, Dual-band) - ebay link
Cudy AX3000 (Tri-band, Mesh Wifi 6) - ebay link
Linksys Velop MX5300 (Tri-band, Mesh Wifi 6) - ebay link
Ubiquiti UnFi U6-LR (Wifi 6, Dual-band) - ebay link
:::
As for switches, I just need it to be managed (VLANs), have 4 ports (one for homelab PC, one for the AP, two extra for future). Here’s the ones I looked at: ::: spoiler
TP-Link Omada ES206GP (6-port, 4 ports are PoE) - ebay link
Ubiquiti UniFi USG-PRO-4 (4-port, does include two SFP ports) - ebay link
HP NJ5000-5G (4-port, 2 ports are PoE) - ebay link
HP MSM720 (4-port, 2 additional SFP ports) - ebay link
TP-Link ES205GP (5-port, 4 ports are PoE) - ebay link
Cisco RV220W (4-port) - ebay link :::
Ansible. At least that I’ve found.
Admittedly I haven’t used Omada even though my gear supported it (before I flashed OpenWRT on it), but I don’t think it bears any resemblance to Ansible except in the most basic sense of being able to accomplish administrative tasks somehow.
What I was expecting was something that would provide a web dashboard showing all of my OpenWRT (and ideally, misc. other devices) at once, maybe with a nice diagram of the network topology and stuff like that.
When you look at existing self-hosted messengers, you usually see one of two things: either complex infrastructure that’s hard to deploy (Matrix/Synapse), or minimalism with no encryption. ONYX is an attempt to find the middle ground: easy to deploy, real E2E encryption, and the ability to work entirely in a local network without internet at all.
| Component | Technology |
|---|---|
| Client | Flutter (Android, Windows, macOS, Linux) |
| Server | Node.js — Express + express-ws + ws |
| Database | MariaDB + Redis (sessions, cache) |
| File storage | S3-compatible (AWS SDK v3) |
| Transport | WebSocket (wss://) + HTTP/REST |
| Encryption | X25519 + XChaCha20-Poly1305 + AES-256-GCM |
One of the key features of ONYX is the ability to communicate in a local network without internet at all. A custom device auto-discovery mechanism handles this entirely.
Every client broadcasts a JSON packet to 255.255.255.255:45678 every 5 seconds:
{
"username": "alice",
"timestamp": 1710000000000,
"pubkey": "<X25519 public key, base64>"
}
All other clients listen on that port and update two local tables:
username → source IP addressusername → X25519 public keyNo mDNS, no manual IP entry — just pure UDP broadcast. The public key is included directly in the broadcast packet, so encrypted communication can start immediately without an additional handshake.
Media files go through a separate channel on port 45679, split into ~32 KB chunks. Each chunk is encrypted independently with AES-256-GCM, which allows decryption and rendering to begin before the full file is received.
No RSA anywhere in the project — only a modern elliptic curve stack.
onyx-lan-v2 for LAN, separate labels for E2EE chats)Packet format:
[pubkey 32B] [nonce 12B] [ciphertext] [mac 16B]
AES-GCM requires hardware acceleration (AES-NI) for decent performance. XChaCha20-Poly1305 runs in constant time on any hardware — important for mobile devices without AES-NI. It also has a wider nonce (192 bits vs 96 for GCM), which reduces collision risk in long sessions.
AES-256-GCM is used for LAN media transfers — chunked delivery, and hardware acceleration is available on most desktops.
When a new device connects to an account, it sends an authorization request to a trusted device. The trusted device must explicitly approve the new one — only then does the key exchange happen. The server never has access to decrypted content, even when adding a new device.
When a message arrives, the server sends it to each of your devices separately — encrypted with that device’s specific public key. Technically these are different encrypted messages for each device, just with the same plaintext inside.
One honest limitation: only incoming messages sync across devices. Outgoing messages are visible only on the device they were sent from. Full bidirectional sync with E2EE requires either a “copy to self” encryption mechanism or server-side plaintext storage — both are worse tradeoffs.
The requirement from day one: one codebase for Windows, macOS, Linux and Android. Three options were considered:
| Option | Problem |
|---|---|
| Native development | 3–5 separate codebases, constant desync |
| Electron | +150–200 MB RAM, DOM rendering |
| Flutter | Single codebase, Skia/Impeller, real 60fps |
Flutter Desktop required writing 10+ separate optimization modules (fps_booster, fps_optimizer, fps_stimulator, message_load_optimizer, chat_preloader) — Flutter on desktop lags noticeably without tuning. But the result is smooth UI across all four platforms from one repo.
proxy_manager.dart, routing through any proxyTwo types of groups and channels in ONYX — fundamentally different models.
Standard groups and channels work through the central ONYX server and are not encrypted — a deliberate tradeoff for reliable sync. Suitable for open communities where E2EE is not a requirement.
Anyone can run their own instance — on a VPS, home server, or local network:
| Use case | Description |
|---|---|
| Local network | File sharing and chat within office/home network, no internet |
| Private community | Closed group on your VPS, join by invite |
| Public channel | You host it, subscribers read posts |
Connect to any external server directly from the app — enter the instance address and join.
Server software — ONYX Server: github.com/wardcore-dev/onyx-server
ONYX has a dedicated Favorites tab — not a “Saved Messages” clone, but a proper local notebook. Create any number of favorite chats, each with its own avatar and name, as separate categories: passwords, ideas, saved media, links.
Everything is stored locally on the device — nothing sent to the server, nothing synced. The server knows nothing about your favorites.
Project is in working beta. Development is ongoing. Happy to answer questions in the comments.
Hey bud, this is a neat project! I ran your codebase through my own Claude Opus 4.6 instance with extended thinking on, against a “code quality” skill I worked up with the bot the other day. The skill prioritises security, code efficiency, and enforcing end-user usability over taking shortcuts. It found a lot more than the 8 security issues I opened, but I didn’t wanna flood your issues section until I’m sure you’re happy for me to contribute like this.
Anyway, cheers, and good luck!
Write to @support directly in ONYX, using the search field, and we’ll discuss this in detail.
https://lemmy.world/pictrs/image/d77bb5f6-2d58-4499-ab10-36cd4d741660.png
When you look at existing self-hosted messengers, you usually see one of two things: either complex infrastructure that’s hard to deploy (Matrix/Synapse), or minimalism with no encryption. ONYX is an attempt to find the middle ground: easy to deploy, real E2E encryption, and the ability to work entirely in a local network without internet at all.
| Component | Technology |
|---|---|
| Client | Flutter (Android, Windows, macOS, Linux) |
| Server | Node.js — Express + express-ws + ws |
| Database | MariaDB + Redis (sessions, cache) |
| File storage | S3-compatible (AWS SDK v3) |
| Transport | WebSocket (wss://) + HTTP/REST |
| Encryption | X25519 + XChaCha20-Poly1305 + AES-256-GCM |
One of the key features of ONYX is the ability to communicate in a local network without internet at all. For this, a custom device auto-discovery mechanism was implemented.
Every client broadcasts a JSON packet to 255.255.255.255:45678 every 5 seconds:
{
"username": "alice",
"timestamp": 1710000000000,
"pubkey": "<X25519 public key, base64>"
}
All other clients listen on that port and upon receiving a packet update two tables:
- username → source IP address
- username → X25519 public key
No mDNS, no manual IP entry — just pure UDP broadcast. The public key is included directly in the broadcast packet, which allows encrypted communication to start immediately without an additional handshake.
Media files go through a separate channel on port 45679, in chunks of ~32 KB. Each chunk is encrypted independently with AES-256-GCM, which allows decryption and rendering to begin before the full file is received.
No RSA anywhere in the project — only a modern elliptic curve stack.
onyx-lan-v2 for LAN, separate labels for E2EE chats)Packet format:
[pubkey 32B] [nonce 12B] [ciphertext] [mac 16B]
AES-GCM requires hardware acceleration (AES-NI) for decent performance. XChaCha20-Poly1305 runs in constant time on any hardware — important for mobile devices without AES-NI. An additional bonus is the wider nonce (192 bits vs 96 for GCM), which reduces collision risk with a large number of messages in a single session.
AES-256-GCM is used for LAN media — chunked delivery, and hardware acceleration is available on most desktops.
One of the trickiest cases — a user with multiple devices while keeping E2E encryption intact.
When a new device connects to an account, it sends an authorization request to a trusted device. The trusted device must explicitly approve the new one — only then does the key exchange happen. This means the server never has access to decrypted content, even when adding a new device.
Private chats work through the central ONYX server with E2EE. Technically, multi-device works like this: when a new message arrives, the server sends it to each of your devices separately — encrypted with that device’s specific public key. Technically these are different encrypted messages for each device, just with the same plaintext inside.
One honest limitation: only incoming messages sync across devices. Outgoing messages are visible only on the device they were sent from. This is a deliberate tradeoff — full bidirectional sync with E2EE requires either a separate “copy to self” encryption mechanism or server-side plaintext storage. Both options are either more complex or less secure.
The requirement from day one: one codebase for Windows, macOS, Linux and Android. Three options:
For a messenger with active animations, media and chats the rendering difference is significant. Flutter Desktop required writing 10+ separate optimization modules (fps_booster, fps_optimizer, fps_stimulator, message_load_optimizer, chat_preloader) — Flutter on desktop lags noticeably without tuning. But the result is smooth UI across all four platforms from one repo.
proxy_manager.dart, routing through any proxyTwo types of groups and channels in ONYX — fundamentally different models.
Standard groups and channels work through the central ONYX server and are not encrypted — a deliberate tradeoff for reliable sync. Suitable for open communities where end-to-end encryption is not a requirement.
Anyone can run their own instance — on a VPS, home server, or directly in a local network. Use cases:
A group is two-way communication — all participants can write. A channel is one-way broadcast — only admins publish, others read.
Connect to an external server directly from the app — enter the instance address and join the group or channel.
There’s a dedicated server software — ONYX Server, available at github.com/wardcore-dev/onyx-server:
git clone https://github.com/wardcore-dev/onyx-server
cd onyx-server
npm install
cp .env.example .env
node server.js
Dependencies: MariaDB + Redis + any S3-compatible storage (MinIO works for a fully local stack). Runs on a $5/month VPS.
ONYX has a dedicated Favorites tab — not a “Saved Messages” clone, but a proper local notebook. You can create any number of favorite chats, each with its own avatar and name, and use them as categories: passwords, ideas, saved media, links.
Everything is stored locally on the device — nothing is sent to the server, nothing is synced. The server knows nothing about your favorites.
Registration requires only a username and password. No phone number, no email — a deliberate decision to keep minimal data on the server.
Your username is chosen once and forever — it cannot be changed. It’s your permanent identifier in the system. You can change your display name, but not the username itself.
Multi-account: register and hold any number of accounts in the app, switch between them freely.
Account deletion: delete your account at any time along with all media and server-side data. No traces left.
The project is in working beta. Development is ongoing. Happy to answer questions in the comments — especially about the crypto implementation or Flutter Desktop specifics.
Try it out — github.com/wardcore-dev/onyx-server
Tags: #flutter #node #encryption #selfhosted #privacy #opensource #security #webdev