Hacker News Reader

Comment by huhtenberg | Hacker News Reader

Excellent stuff. I especially like that this focuses on solving an actual, very specific problem rather than being some amorphous platform.

That said and if I read you correctly, the backend must be some sort of a dumb relay that just routes blobs of data between clients based on how they are grouped. Correct?

If so, then nothing restricts you from relaying any type of data, which is a fantastic foundation to have.

Do you have any details on how two clients would establish trust, exchange keys, if there's a replay protection, etc.? It would make for a good read.

PS. One thing I'd change is the name. It's just... not nice, unpleasant. It also doesn't help that it means an "itch" (зуд) in some languages, the kind you get from not taking a shower for a month.

View on HN

Hi huntenberg. Thanks for the thoughtful reply. :-)

> That said and if I read you correctly, the backend must be some sort of a dumb relay that just routes blobs of data between clients based on how they are grouped. Correct?

You're correct. It is just a dumb relay. That's the reason why it's so difficult (impossible?) to come up with a freemium monetization strategy. The server can't see the contents of your communications, so it can't restrict functionality.

> If so, then nothing restricts you from relaying any type of data, which is a fantastic foundation to have.

I suppose so. What did you have in mind?

> Do you have any details on how two clients would establish trust, exchange keys, if there's a replay protection, etc.? It would make for a good read.

I don't have anything written up about this (other than the code in the repositories), but if there's interest, I could compose a blog post about it. For the time being, users can verify the privacy of the communication with another friend by comparing the safety number of the friendship (tap the friend's avatar on the map, in the info panel that pops up click the triple dots at the top right, then select 'View safety number'). If you're safety numbers match, you know your share with that friend is secure. I got the idea from Signal messenger.

> PS. One thing I'd change is the name.

Yeah, I'm still reconsidering the name. I've already changed the company name once, but I may have to change it again. It's just hard to come up with an easy to remember+spell name that also has an available domain.

> That's the reason why it's so difficult (impossible?) to come up with a freemium monetization strategy.

I'd say that you may want to charge for the actual service rather than for relaying per se, but still base it off the quality of service. For example, will having near real-time updates of other people's location be worth $X/mo? Heck, yes. Should you charge for one-off manual checks? Probably not.

So, have a manual and automatic modes. With manual, if I want to know what my friend is, I have to tap a button and it will ask the relay to ask the friend's phone for its location. Cap this to, say, 1 request a minute and give this away for free. Then add an automatic mode whereby the relay will automatically poll my peers for their location. Charge for this. Also allow very easily enabling this mode for a fixed period of time, say, just 24 hours or 1 month or allow subscribing to it. This will take care of people who need to track someone's location only occasionally. Charge more for this (or, alternatively, give massive discounts to those who subscribe).

Next, have tiers on how often updates are collected. 1 minute, near real-time, etc. Price accordingly.

Next, cap the length of the peer list that people can have for free.

Next, on the server side retain only the last update by default, but allow retaining full (or extended) history. Charge for this, charge to the _consumer_ of this information.

Next, allow people organizing themselves into groups, with every one sharing their location with everyone else. Charge for that, charge it to the group owner.

Next, allow groups to have a "star" topology - all members reporting to a single "admin" user. This is now getting into the enterprise-ish use, so you'd probably want to have a "managed" version of the software that will have all UI locked down. This will also jive nicely with the history retention.

Next, add a separate management/admin software for herding group installs. Alternatively, offer an option of using a web interface in exchange for relinquishing the privacy.

...

I mean it's not that hard :) Start small, solving one specific need of a specific user group at a time and then extend logically.

Reply on news.ycombinator.com