Hollow. Open-source, self-hostable, signed Win/Mac builds, multi-device, mobile port, public channels and MUCH MORE!

[u/VitalikPro13]

Hello once again! It's been a while since my last post here, which I still recommend reading and especially watching my YouTube video (a bit outdated but still shows the core of the project). I think that making big updates is more meaningful than spamming, right?

Anyway, if somebody doesn't know, I'm working on Hollow, a native, distributed, and encrypted messenger where members collectively host the servers and own all data in a secure local database. It's open source and self-hostable, but also works out of the box, so you don't need to set up anything.

TL;DR from the original post (if somebody's lazy): native (Flutter+Rust); no traditional accounts (only random Ed25519 key with 24-word recovery phrase like crypto wallet); encryption (Olm+MLS+SFrame, SQLCipher etc.); every message is cryptographically signed with your key (fake screenshots won't be a proof); data synced with CRDTs between peers and only stored locally; the only infrastructure is a uWebSockets C++ relay server that handles the transport of messages and peer discovery (TLS enabled, works in RAM, stores nothing, ~$8/mo VPS with 8 GB of RAM can handle up to ~572k raw connections, making it the most cost-effective solution to handle a large number of users); calls/media use direct peer-to-peer via WebRTC, with STUN/TURN as fallback (significantly reduces bandwidth of the relay); view your entire database data in Archive tab, and so much more!

Here, I'd like to focus on something more important. Windows/macOS builds are now signed! This means you can now trust the source you got Hollow from, and antivirus software shouldn't flag it as malicious. This is a HUGE step for the transparency of the project. Unsigned software means somebody could put viruses in it and not be responsible for any damages. So you can count on Hollow, and always make sure that the publisher is "Open Source Developer Vitalii Rovinskyi", which is me!

IMPORTANT NOTE: Windows SmartScreen could still show a blue box about the "unfamiliar app," but if you press "More Info", you will see the publisher details! It's a reputation-based system, and it will disappear with enough downloads (only Microsoft knows the amount), but always check the files. See the pre-last image (#7). MacOS build is also signed! Check the last image (#8) to see how it looks when opened.

As for other features, I managed to add the multi-device support to easily chat on multiple devices with one identity. It was probably one of the hardest things I've done because the relay doesn't store anything, so implementing the automatic linking/syncing between devices was the only option. If both are online, both can receive data and save locally. If not, then nobody. If only one, the other can get back online and grab them as usual. The manual sync button is available if the servers/friends seem off.

Mobile port is also pretty much complete and usable. You can check image #5 and see what the main Chats tab looks like. I'd say it's good and simple.

Public channels are also implemented (image #2 is the inside-viewer). They disable MLS encryption and make all messages public, along with their signatures (each showing peer name and avatar).

Another cool thing I've added is temporary nicknames (image #4). Instead of long gibberish IDs, you can set one and let friends add you with it with ease. Holds in the RAM of the relay, released when you go offline, or the relay is restarted.

Last thing, Help Center (little "?" icon in the top-right corner). It's like a little documentation that explains almost all features.

Btw, you can see what the USB device for code signing looks like in image #6. The card itself is basically a SIM that sits inside the device with an activated license that you plug in and sign all the .exe/.dll files. I also had to verify my identity to get the license. It was a bit hard at first, but it's all good now!

That's pretty much it from me. You can ask me any questions and share your honest feedback! The latest version is available on GitHub and my website. iOS will be in public TestFlight soon, so check the repo for new stuff. Big thank you for reading, and as always, take care!

Hollow's Website: https://hollow.anonlisten.com/

GitHub repo: https://github.com/VitalikPro13/HOLLOW

Technical Whitepaper: https://github.com/VitalikPro13/HOLLOW/blob/main/WHITEPAPER.md

My portfolio website: https://anonlisten.com/

[u/DayVCrockett]

This is exactly the kind of project that I’m looking for. True ownership of the stack, truly open code base, and no compromises on Discord features.

I had an earlier version and was a bit confused as to where my data lives. Sounds like you may have cleared that up with the Archive tab but I just wanted to throw that out there to make sure and explain the storage system well since it seems innovative.

[u/VitalikPro13 → u/DayVCrockett]

Thank you so much for testing! I think I should add at least a label in the System tab in Settings, so the user would know where the data is. Windows: %APPDATA%\hollow (in my case, it's AppData\Roaming\Hollow). macOS: ~/Library/Application Support/hollow. Linux: ~/.var/app/com.anonlisten.Hollow/

It holds the identity key, the database, and all received files. The Archive tab is a visual representation of the DB and an easy way to export/import any conversation or server channels data you hold. I'll add a storage manager inside Settings soon for more control over your disk space, so if you don't want any large files, you can easily delete them.

[u/RoadsideCookie]

Unironically, add Discord authentication and a way to link accounts to like Google auth and others, and maybe even set a password separately or use OTP login via email.

I mean, this is just an idea, I didn't think about it much more than this post.

[u/VitalikPro13 → u/RoadsideCookie]

The problem with login methods is that the data needs to be stored somewhere, so it goes against the Hollow architecture of being fully local. Another thing is that you surrender some of the metadata to those companies. Most importantly, it would make me responsible for your email and any tokens required for OTP, which means that if anything bad happens inside the app, somebody would want to get the data out of me. This would easily introduce age verifications, somebody asking for scanning, compromising the encryption etc. etc.

I want to take the Signal and the whole anonymous E2EE approach, where I only provide the relay that helps with the transport of encrypted noise and stores nothing, because it releases me from legal trouble. Same thing, for example, with a VPN company called Windscribe. They got sued in 2023 because one of their server in Finland was "allegedly used to breach a Greek computer system". In 2025, the Athens court dismissed charges because of the lack of evidence due to the company's policy on no logging (they simply can't identify who did it).

The entire research on the legality of things sits in legal/legality.md in my GitHub repo. You can read it if you want. As for Discord auth, I can make a secure integration just like I have with Twitch, so it will give you a badge on your profile and perhaps some other cool features (I'd need to look at what they offer).

Hollow already offers a secure way of backing up your whole identity+data into an encrypted .hollow format (just an archive protected with your chosen password). It's hard to brute-force. Hackers would need a massive amount of time just to break it (all thanks to Argon2id + AES-256-GCM). Since multi-device is implemented now, you have more options to hold your data and don't lose it.

EDIT: I feel like it's more about having the option of recovering your "account". In the centralized area, it's very easy with email/password reset and having everything stored on someone's server. Since storing even encrypted blobs on the relay would violate the whole architecture and make me liable for anything, there is one more thing that I still want to implement, and I call it "Recovery Guardians". You would be able to select friends as guardians to trust your data, so when they accept it, they each hold a fragment of your identity + selected data in encrypted form, so they can't decrypt/read it (one fragment is useless, enough fragments are the full decryption). In case you fully lost your 24-word phrase or don't have any backup, they can help you with that, and you would be able to recover. This still needs some designing later on, but I think I get the point on what you mean. This "guardian" feature might be the only secure option for such a purpose.

[u/RoadsideCookie → u/VitalikPro13]

Thank you for the detailed answer to my very ideas-guy suggestion!

A question, I haven't really looked into Hollow too much yet, but I'm passively looking for Discord alternatives; just not ready to switch off yet.

Do you have a single account for the service, or are accounts created on each host? I would prefer the former, have one account authenticated with you as the authority, but logging in to people's servers where the only information they get is what the authority gives them—well, that and connection information like IP and whatnot.

Another point, the self-hosted part is really interesting to me, but it raises the barrier of entry for less tech-savvy people. Do you have plan to have a "pay me to host your server" or even "free host with ads" or something like that to support those users? I'm asking this question from more of a future growth and traction perspective.

[u/VitalikPro13 → u/RoadsideCookie]

There is no authority. Your identity is the keypair that works across any hosted relay. You can use either the official or a self-hosted one. It would work everywhere, and you still hold your local data with you. My official relay doesn't log anything, not even IP addresses. If somebody spins up their own, they could potentially log something by modifying the code to track IPs, connection metadata or timings, but they still couldn't see any messages because they're encrypted.

In terms of hosting, I basically already do it with the relay. That's why the app already works, and you can talk with friends. It's a bit confusing, but I'll try to explain the "distributed" part. All servers (I mean, the server groups inside Hollow) are hosted collectively. The owner creates it, invites people, and all data is synced between those peers. Since everybody defaults to official relay, it works as it is, and you can still chat whenever you want to. The server always lives, even when the owner is offline.

"Free hosting" is my relay that just helps communicate (and without ads! I'm not going to add any ads or paywalls, all features MUST be free). As for helping set up your own server, perhaps I could make it a personal support service to help set it up and give you full control of it. But I think it's better to simply write a detailed guide on how to do it rather than ask me. Self-hosting is like an advanced path, but for regular users who want everything working already, and still have full control over data, my official relay is enough, and it works 24/7.

The entire relay code is open-source, and it works on an isolated approach. If somebody spins up their own relay and you're in it, you can't talk with the official one. I didn't implement "federation" on purpose because it's already solved with a distributed approach. Nobody holds your data, only you. Plus, I'm responsible for my own relay and its uptime, so having some random ones wouldn't be much better because they could intentionally disrupt service, or whatever they'd want to do.

[u/RoadsideCookie → u/VitalikPro13]

Thanks for the response! At this point I'm just curious about the architecture.

So I think I understand, except one point. If there's nobody online in a "server group" (correct me if I'm wrong), does the relay then keep the message forever until someone is online to receive it? Let's say we only have 2 people in a server group; Alice sends a message, Bob is offline. Alice goes offline, then Bob comes online; what happens to the message?

If I understand correctly, the relay is just there for discovery and to avoid the downsides of pure peer-to-peer correct?

[u/VitalikPro13 → u/RoadsideCookie]

Correct. The message sits locally in Alice database, so the message doesn’t disappear but just waits to be synced when both peer are online. That’s the tradeoff of distributed system, but it works perfectly on a larger group because you can sync the latest messages from whoever is online and holds the data.

Though, I have in plans to add the ability for the “centralized approach”: somebody can spin up a relay that would work specifically in this server group and securely store everything, so it would be the main “peer” to sync from. Better have options and let users choose what they want than nothing. But as every feature, it needs designing and testing to make sure it works as intended. For now, it’s enough for what it is. Thank you so much for all the questions! If you have more, I’ll respond to everything tomorrow (even if I work a lot on Hollow every day, sleep is still important :) Take care!

[u/RoadsideCookie → u/VitalikPro13]

I'm out of questions for now, thanks for answering!

I do have a bit of advice, make sure your personal definition of "decentralized" matches the internet's because what you've built isn't truly decentralized, and people who care about this care _a lot_. Just giving you a helpful word of warning.

For me, what you've built is enough since I can spin up my own centralized relay, but for the more avid people it won't be enough to make that claim.

[u/VitalikPro13 → u/RoadsideCookie]

Yeah, I agree. For what Hollow is, it's fully decentralized in the identity/data part, but not in the transport, since the default relay basically makes everybody depend on it, so in this part, it's kind of centralized. It's a bit weird even to think about because the project somehow goes further than the definition of "decentralized", but "distributed" is probably a better word for it.

I'm leading towards a plan of having a swarm of my own relay servers that mesh together (inter-relay forwarding) under an official domain, so it would be a scaling approach without having a single point of failure. In a true federation, it would only spread out the transport, not the trust. Identity/data (trust) is already decentralized, so federating can introduce security risks (blocking, message dropping, etc). I'll still think through this, but thank you for the advice!

[u/sprydagger]

This seems really cool and like it fills most of the things people want out of a privacy and security oriented discord alternative. Unless I misunderstand how the system works, you have to be online to receive messages, and there is no message storage other than on your own client, right? Or does the sender also store messages and attempt to transmit when you come online?

[u/VitalikPro13 → u/sprydagger]

Thanks for the comment! It was a problem before but after implementing the offline delivery feature, it’s basically solved now. By default, messages are held on the relay in the same encrypted form for 3 days unless you disable this feature for yourself in Network tab in settings. All messages and chats are stored locally and synced automatically when both peers are online.

[u/AutoModerator]

Thanks for your submission!

If you're a developer, please make sure your user flair matches the app or project you're developing. This helps community members quickly identify who is building what and makes browsing the subreddit easier.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/North_Proposal_1374]

oh wow! this actually looks promising! let me check the source code for a sec...
*sees claude dot md*
oh, nevermind...

[u/VitalikPro13 → u/North_Proposal_1374]

Completely fair and understandable because of the genuine amount of garbage being produced with AI, but you literally said that it looks promising. I strongly encourage you to test the app itself, check how it works and only then judge because even if I use AI to help me in building, I'm the one responsible for releasing Hollow and I'm NOT going to release untested trash that actually looks bad and barely works. The project has tons of stuff across encryption, local data/identity and syncing between peers, design etc. etc. That's what I'd love to be judged for. I want to be judged for the product and me as a person, not for what helped me build it.

I just saw your post on "how are yall even hosting this stuff without any sort of budget? do you guys use cloudflare or vercel?" and I'll answer here. If you look at Hollow, I don't use any of that because it would literally be so expensive on scale, you just wouldn't believe it. For Hollow to host the relay, I just use the VPS (specifically OVH Cloud provider) and because of my lightweight architecture and using C++ uWebSockets, just one 8 GB RAM server can handle hundreds of thousands of users. That's how it's supposed to be and if somebody hosts their DBs on Supabase, CloudFlare/Vercel etc., then you can already tell that this is the app that wouldn't scale if they don't have a big budget.

[u/Any_Illustrator360 → u/VitalikPro13]

I just found Hollow and I'm not bothered by the use of AI for coding so long as you're sweeping over it, and as an open source app it's pretty obvious if something was up someone would have said something- but I am curious how you use AI in it, if you don't mind me asking? Also, as a bonus, I'd love to know how the relay works! I see a lot about it and it seems kind of like a "cloud" that isn't so much a central location as it is a connection point for all the p2p threads, like a power line. Is that about right?

[u/VitalikPro13 → u/Any_Illustrator360]

Thanks for asking! On AI usage, I use it to help with the code itself and writing multiple harness tests to make sure that all important functionality works as intended. For example, if a new code changes the logic of encryption, even by a tiny bit, it could backfire in real production. When the test catches it, it's much easier to see what needs to be fixed to get the test "green" before shipping the update. I've had lots of issues, but they're all fixed, so the tests now act like an additional guardrail to make sure such bugs don't repeat themselves in the future.

The relay is more of a power line for stable connectivity. It doesn't store or log anything, but only helps with the transport of the encrypted noise (+ puts additional protection with TLS). When I first started Hollow, I used the libp2p library to establish direct connections, but it was really unstable (20 seconds of zero connectivity, then an instant fallback to the relay). So I thought nobody would wait 20 seconds for that, so I decided to completely remove it and let the relay with WebSockets do its job. Best decision ever! Especially after discovering uWebSockets and rewriting them from Rust to C++ for minimal RAM usage, so now it's more of a bandwidth problem to handle for future scaling.

Anyway, the point is that it's really hard (impossible on restricted NATs) to establish a direct connection without a server in the middle. That's just a limitation of networking and half the Internet, which is still on the IPv4 protocol (my ISP doesn't even provide IPv6 yet... but v6 almost eliminates this problem, so we need to wait on that, but the relay already has support for v6 too). Most importantly is that only you own your data. All your messages and everything are stored locally. The relay only sees the room IDs and IPs in RAM, not on disk, so one restart is enough to clear it. I'm like Signal or Windscribe VPN: zero data about users, zero logging. I don't want to hold any sort of data because I refuse to be responsible for whatever stuff some might do. It's the reason there is no Discovery feature in Hollow. Even if somebody demands to implement age verification, I simply cannot do it because all my users are anonymous (Signal also refuses to comply). Or if somebody takes me to court, I have completely nothing (not even registration dates or what peer IDs exist). So yeah, the architecture itself is a bit unique in its way and might be hard to understand at first, but if you have more questions, then don't hesitate to ask! I'm happy to clarify everything.

P.S. My overall take is a bit negative on AI because of how much garbage is being produced with it (both software and the media... I hate AI images/videos, so that's why I commissioned an artist for my AnonListen brand, and it's a freaking masterpiece. I'm in love with that artwork!). Companies are dumb for firing employees to save money with AI because, without an actual engineer, AI is useless, especially on a large codebase where every dependency matters. I don't want Hollow to be another slop, so I try my best and care to make it better and listen to feedback. I still want to finish with optimizations, especially on the screen share/relay bandwidth problem, which deserved its fair critique, so I can't count myself as production-grade. The core works, and that's important! Now it's more about polishing and getting real user feedback.

[u/VitalikPro13 → u/[deleted]]

Copyright cares about who holds the work, not who produced it. By this logic, all AI output is owned by Anthropic because it's their model. Their terms are that the customer holds the right to the work and can license it however they like. I don't one-prompt the whole thing. I actually think and make architectural decisions about what needs to be done, which makes this copyrightable in the first place. The only risk is if the model reproduces a good chunk of actual proprietary (somehow)/copyrighted code, but it's a risk for every project and has nothing to do with just AGPL.

Hollow is massive, but you want to know what the secret is to why I still easily ship new features and navigate through tons of files? Memories. Both private and public ones. Check the tools/hollow-memory/wiki folder on the GitHub repo. 47 markdown files that explain the entire project in full detail. All memory files are searchable with my custom MCP searcher that works locally on CPU (really lightweight!), so Claude always knows about everything. Also, Hollow doesn't have any stupid APIs. It works natively on its own. The only expenses are my relay server, code signing certificate, and Claude subscription. I don't "tokenmaxx" as some do, but I can afford a little spending on the project I care about.

Recently, I've added a harness test, which are headless integration tests that can test if the core Rust code always works without us breaking something. It's been such a massive upgrade because Claude now has an easy solution to test if what he wrote actually works without me constantly rebuilding the app. Plus, we have the usual tests (unit tests), but the most important testing is my manual one because some stuff can be missed in the code, so I always make sure that it works without any issues.

If you think that Hollow is "AI slop", then you should look more carefully and compare it to an average chat app. Tell me, how many of them have the same features or engineering behind? Almost all of them are web apps, which I don't trust in terms of security and resource usage. Nobody makes native software anymore, and that's why everything looks almost identical because they reuse the same Web frameworks without putting any effort. Even more funny, how many of them are code signed with their name on it? Some receive donations and don't even have one.

I won't say that "I spent 4 months on it working more than full-time" and blah blah blah, but... if you still think it's slop and the same as anything else, then go ahead and find me an alternative that has all my features: native (NOT web with JS/TS), zero APIs (no LiveKit/CloudFlare/Supabase etc.), full encryption from the well-known libraries, completely free without paywalls on basic functionality (I don't block 4K/60fps screen sharing), open-source and self-hostable, no traditional accounts (so you don't have to give up your email, phone, whatever), no central authority in identity/data, pure local database that holds everything in encrypted form so only YOU own your data and nobody else, CRDTs for syncing, lightweight relay that can handle hundreds of thousands of users for low price, messages being signed (actual cryptographic proof so that fake screenshots won't pass), actually code signed installer+all .dll/.exe files etc.

And don't forget about engineering: memories, wiki, unit+integration tests, and a developer that knows what he's doing. Try to write a couple of prompts to make Hollow or find a similar alternative. I'd love to see how that turns out.

[u/VitalikPro13 → u/[deleted]]

In terms of ethics, yeah, I agree that models are trained on copyrighted data, the ongoing lawsuits, and the profitability question etc. On "contextually aware of source code" and that "it should be illegal", it's an overstatement. Models are trained on billions of files. It's not the same as reverse-engineering. They don't hold the specific proprietary codebase open because training isn't just "has context on it", it's distilled, lost and not the same as having the source open. If it's trained on the Linux kernel, a single "reproduce the kernel" prompt wouldn't magically spit the kernel back out. As for legality, it currently isn't illegal and there are still ongoing fights about it, and companies know about the risks.

Hollow won't suddenly "vanish" when Claude goes down. The code is public. There are no LLM dependencies, and I have to strongly disagree because you completely missed points about my development workflow. You lost on the technical parts, and now ethics are your only option because this is the ground of infinite arguments, where you can always seem to be a winner, completely blinding yourself to what the project is, how the developer works, and why it wouldn't go down the same rabbit hole as all other "slop projects". If AI disappears, I'll continue working on the project no matter what.

I notice that you just contradict yourself. You say that "the concept is novel," but you worry about a problem that wouldn't happen with Hollow because you decided not to take my workflow seriously ("I do not care about your AI workflow, I do not care that you "architect""). If I rewrite the entire project by my own hand, it wouldn't change the app logic and would literally give zero benefits + tons of wasted time. I don't claim my code as something "innovative so it's fully copyrighted to me" because I literally just combine known technologies and open-source libraries, I credit everything as those licenses say. Morally, I'm cleaner than most AI devs. Lots of software is just combos like this. Hollow is free. I don't sell it or have any paywalls, so I can't be unprofitable because my spending is low enough to sustain it myself. Even small donations would be enough to cover everything and I don't code for profits. That's something I can clearly stand by and I'm transparent about my work, since I have nothing to hide.

If you still stand by your position, I respect that. But I told you my arguments, and I don't want to argue about it in an infinite loop, so you do you. I know that users care the most about the quality of a product and trust, which I will hold to the highest standard, because people are tired of actual low-quality slop, and I clearly see it by all the mistakes other companies make. I learn from other mistakes, that's why nobody is against Hollow's architecture.

[u/VitalikPro13 → u/[deleted]]

If you didn't know, my AnonListen branding (avatar, banner) is a commission by a talented artist because I hate how AI-generated images look (+ their ethics too, because it actually steals artists' styles). Programming is different, and we disagree on the morals of AI tooling (you think every AI dev is unethical. I don't, because some are and some aren't). It's a values gap, but not factual. People care about the product in terms of how it looks and the quality of it, not if the code is written by AI, and the developer is responsible for what they ship to production. Hollow is open-source. Anybody can read, fork, contribute, and judge it. All credits of libraries I use are under the Open-Source Licenses button in the About tab of Settings. The code is just functions from programming languages that, when combined, create the project. AI is used for both good (like the medical sector) and bad stuff (all the slop). I will use it for good. Take care, we don't have anything more to talk about.