For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | Realman78's commentsregister

https://github.com/Realman78/Kiyeovo - I'm currently working towards the full release of my P2P dual-network mode messenger which is currently in beta. The reviews were overwhelmingly positive when I released the beta a week ago so that motivated me to try extra hard to make it pseudo-perfect upon full release

Haha, it's roughly pronounced as it's typed out. The name actually comes from a Croatian dialect. "Ki je ovo" translates to "who is this" -> and then when you connect the words and make it english compatible, you get kiyeovo.

If you go to google translate, select Croatian input "kijeovo" and click the speak button, you will hear how it is properly pronounced. Not that I care how people pronounce it, just wanted to share :)


The two modes are in one app for convenience, but they are separate systems. IMO, the risk is not data leaking between mode protocols/DHT, but rather the user linking their identity between the modes through their behavior - reusing usernames, same contacts... So in short, it's ease of use vs the risk of user error

Yes, I agree Tor is not the best anonymity service these days. I2P was my first choice, but the performance was just awful. I did not fully give up on the I2P idea, maybe it was just that day, so I will give it a second choice and mazbe add a third mode or fully replace tor. Not sure since a lot of people are familiar with tor, and not I2P

Whom you want to please with TOR support.. You have advantage not being a commercial product driven by recognition, to be free to base it on the next and better thing.

QR code key exchange is convenient, but I did not plan phone support.

Nobody does "face to face" key exchange like I imagine. Just two phones facing each other spamming QR codes for the other to read.

What I REALLY want is an app that builds a big bank of nonces between you and your peers over short range radio or QR codes and then lets you use a 1-time pad.

Ultimately, I'm only offering criticism because I have spent a lot of time working on exactly this problem, but I am not in a position to actually implement it. This is awesome and you should be proud of it.


I appreciate the criticism, really. In the current version users only have to exchange the username or peer ID via third party and then find each other on the DHT...

However, there is also another way, which is already implemented and I am currently writing the how-to on my blog site, and that is using "trusted users". Basically, instead of 2 users trying to find each other on the DHT, they can just export their profiles in the "Profile" section. That prompts them to create a shared secret and exports a ".kiyeovo" file. You send that file to the other party, they click on the "+" in the sidebar header ->"import trusted user", select the ".kiyeovo" file and voila!

I know it's not nearly as convenient as what you're describing, but it's just a more "trustable" way of creating a contact which is also not that inconvenient.


Third party info exchange. I don't see that as an issue though. For example, for discord, you also 100% exchanged usernames via a third party system. I mean, even phone numbers are exchanged via third parties. Now that I think about it, the only place where you can search people somewhat reliably are social media sites

In theory, if only Kiyeovo nodes were handling Kiyeovo records, then yes, they could kind of behave like their own subnetwork. The problem is that in a public DHT, the nodes responsible for storing keys are those closes to that key, we cannot guarantee it would be a Kiyeovo node. So even if Kiyeovo clients all use the same validation rules locally, the actual nodes that get hit with the queries do not. The chances of the network converging to the same, correct answer are much slimmer this way

So DHT robustness against censorship is superlinear of the number of participants.

The "break point" is when a DHT gets big enough I can't realistically MITM all the links with nodes "closer to the target" than existing ones.

This means big networks are great, small ones are cheap to just break. Its hard to skip the messy bootstrapping phase.

I'd encourage protocols to only rely on DHTs for small key-value stores if there isn't a trust mechanism in place to validate new peers.

Otherwise, all I have to do is mine for O(n^2) dht keys that cover the network. Figure out what your key mining difficulty is and you can identify what the cost would be.


You're right in general. The main mitigation here is that Kiyeovo does not trust unsigned DHT data: the important records are signed and validated. That doesn't fully solve censorship nor eclipse attacks, but it does stop record forgery. The remaining risk is mostly availability/partitioning - bootstrap connectivity (topology) matters a lot here

Good question. The 4 initial bootstrap nodes that I provided (in the README) are all connected to each other. If everyone connects to all of them, we are all basically on the same network instead of on "isolated islands"

The group creator distributes the updates to each group member individually (each pair of users has their own buckets). Of course, if the member is not online for a long time, the update does not just get lost, it gets republished and will continue to republish until the member has read the update. Did I answer your question?

I’m planning to build something like this over the next few months. Think Nintendo 3DS-sized, but as a tiny laptop. The goal is extreme portability while still being able to program on it reasonably well.

I travel a lot and manage servers, so I’ve been wanting a dedicated “SSH machine” that I can always carry with me. With how good AI tooling has gotten, doing real work on a tiny device is suddenly very viable. The other day I SSH’d into a box from my phone while I was at the gym and just told Claude Code to fix a Kubernetes manifest issue. It was fixed and deployed in under two minutes.

I mentioned this idea at work and a few coworkers immediately said they’d buy one if it existed. Curious what others think.


My first and last Android phone was the Motorola Atrix, which at the time was supposed to be quite good. One of its benefits was the idea that you could pop it into a laptop type dock and have it act as a terminal of sorts.

You can also slap a keyboard onto an existing phone. I have tried vibe coding via ssh from my iPhone and honestly it’s not terrible at all. Instead of doom scrolling I can build things.


I’ve been looking at some tiny laptops. The GPD Micro PC2 is one of my favorites so you can take inspiration from it.


I own a GPD Pocket 2. Terrible support from this company. First of all, my screen had an issue (immediately apparent on first boot) and they refused to solve it. So if you buy such from outside of Europe, buy from Amazon instead of directly, not KS/IGG.

Second, their BIOS is a beta version of a commerciel BIOS, lol. As such, it doesn't have Intel SGX enabled.

That said, it served me as cyberdeck before cyberdecks were all the rage, and before they were easy and cheap to build. It stems from a time when ARM64 wasn't still as powerful as the current (approx) decade. Of course the machine has some downsides for 2026 standards. 2x USB-A, 1x USB-C, for example. I'd rather have 2x USB-C, since you use one for power. I also modded the device for better thermals, and have replaced the battery. The machine sits behind 8 philips screws.

One cool thing the GPD Pocket 3 and GPD Pocket 4 have, is similar to what Framework has: a modular port, where you can keep the form factor but gain KVM, RS232, etc.

The base variant of the Mecha Comet comes with very little storage and RAM:

> This is the base variant with 2GB RAM and 64GB Storage.

And a relatively slow i.MX8. If you want to go with the quicker i.MX95 you're better off with:

> This is the base variant with 4GB RAM and 64GB Storage.

But that one is 50 EUR more, and still comes with only 64 GB storage and 4 GB RAM. My GPD Pocket 2 in 2018 came with 8 GB RAM and 128 GB storage (which isn't much nowadays).

As for the screen in that machine, compare:

> 6th generation Corning Gorilla Glass, AF anti-fingerprint coating, 10-point touch, 500 nits brightness

with

> 3.92" AMOLED Display (550 nits), Capacitive Touch

The screen of this machine, while small (4") seems quite decent.

And if you want to emulate any Android apps which are ARM (which you could with Waydroid, if you have pref. 8 GB RAM on your machine), then you better run ARM. You can emulate x86-64 on ARM with decent performance (tried recently with Qemu on a RPi 4, and my daily driver is a MBP M1 variant) but the other way around is not feasible.


I was doing the same recently and came to the conclusion that i would just get a new small macbook when needed. If I was worried about losing it or damage, I also got a netbook for 20 bucks on eBay the other day and installed Debian on it and as a thin client is more than you need, performance wise.


Nice throwback. I like the idea of 20 dollar netbooks, ordering one for sure! However, the form factor of the product I'm building is smaller than an iPhone XR (that's the only one I have for measure lol), only thicker because it will open up. The point is that I can fit it in my pocket or in someone's fanny pack. With that for factor, you will have to type with thumbs, but I don't mind that. Also, taking inspiration from the Mecha Comet, I could add in a detachable component (keyboard, joystick, etc.)


Also, the netbooks are old now. A new chip with an optimized linux distro will be a joy to work with.


I saw that. Cool, but very expensive. It has a bunch of features that jack up the price but are not worth it for me.


I've been wanting to build something similar, but can't shake the feeling I'd just stick with the SSH client on my phone.

Any reason really to have a separate device for this?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You