HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
Muterra
doc-golix
Security & Privacy2015–2017
Muterra / doc-golix · Archived

doc-golix

PGP-like encryption + torrent-like addressing + blockchain-like enforcement of data expiry

2Distinct people
22Mentions
0Explicit recommenders
122GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

PGP-like encryption + torrent-like addressing + blockchain-like enforcement of data expiry

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:49:33 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month22 dated mentions

Observed mentions: 2015-07-31 00:48:48 UTC to 2017-01-12 18:30:26 UTC.

0123452015-07-01 00:00:00 UTC to 2015-08-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJul 20152015-08-01 00:00:00 UTC to 2015-09-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2015-09-01 00:00:00 UTC to 2015-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-10-01 00:00:00 UTC to 2015-11-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2015-11-01 00:00:00 UTC to 2015-12-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2015-12-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2016-02-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2016-02-01 00:00:00 UTC to 2016-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-03-01 00:00:00 UTC to 2016-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-04-01 00:00:00 UTC to 2016-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsApr 20162016-05-01 00:00:00 UTC to 2016-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-06-01 00:00:00 UTC to 2016-07-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016-07-01 00:00:00 UTC to 2016-08-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016-08-01 00:00:00 UTC to 2016-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-09-01 00:00:00 UTC to 2016-10-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2016-10-01 00:00:00 UTC to 2016-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-11-01 00:00:00 UTC to 2016-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-12-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-01-01 00:00:00 UTC to 2017-02-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 commentsJan 2017

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Jul 20152015-07-01 00:00:00 UTC2015-08-01 00:00:00 UTC101
Aug 20152015-08-01 00:00:00 UTC2015-09-01 00:00:00 UTC413
Sep 20152015-09-01 00:00:00 UTC2015-10-01 00:00:00 UTC000
Oct 20152015-10-01 00:00:00 UTC2015-11-01 00:00:00 UTC505
Nov 20152015-11-01 00:00:00 UTC2015-12-01 00:00:00 UTC211
Dec 20152015-12-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
Jan 20162016-01-01 00:00:00 UTC2016-02-01 00:00:00 UTC312
Feb 20162016-02-01 00:00:00 UTC2016-03-01 00:00:00 UTC000
Mar 20162016-03-01 00:00:00 UTC2016-04-01 00:00:00 UTC000
Apr 20162016-04-01 00:00:00 UTC2016-05-01 00:00:00 UTC000
May 20162016-05-01 00:00:00 UTC2016-06-01 00:00:00 UTC000
Jun 20162016-06-01 00:00:00 UTC2016-07-01 00:00:00 UTC101
Jul 20162016-07-01 00:00:00 UTC2016-08-01 00:00:00 UTC101
Aug 20162016-08-01 00:00:00 UTC2016-09-01 00:00:00 UTC000
Sep 20162016-09-01 00:00:00 UTC2016-10-01 00:00:00 UTC202
Oct 20162016-10-01 00:00:00 UTC2016-11-01 00:00:00 UTC000
Nov 20162016-11-01 00:00:00 UTC2016-12-01 00:00:00 UTC000
Dec 20162016-12-01 00:00:00 UTC2017-01-01 00:00:00 UTC000
Jan 20172017-01-01 00:00:00 UTC2017-02-01 00:00:00 UTC303

What Hacker News says

2 sources
Keybase is definitely working on creating a trust bridge between physical identity and (a specific type of) digital identity. Whether they've managed to do it in a scalable, business-sustainable way remains to be seen. Let me be clear: that's not a slight against them; from a business standpoint I find no good analysis or speculation on their financial numbers and see no publicly commented monetization strategy). The reality of the world today is that if you can't make something economically self-perpetuating, it will almost certainly eventually fail -- especially if the problem you're trying to solve is one of as large a magnitude as literally any social interaction on the internet (they all involve connecting digital identities to physical ones). From a technical standpoint, the primary problem I have with Keybase is that it uses PGP. I
Read the rest
'm not [1] the only [2] person (and, since I'm effectively 100% unknown, I'm far, FAR from the most prominent, who is arguably Bruce Schneier [3]) to criticize PGP, but at the core of it, even ignoring substantial usability issues, have you ever tried to forward a PGP message? It's sort-of possible, if you re-encrypt and re-sign everything, but it's certainly not practical and definitely not scalable. Sharing and re-sharing is the cornerstone of much of the social internet, and PGP renders it effectively impossible. Keybase has a really, really cool body of work surrounding "connect this PGP key to this physical identity", but unfortunately PGP keys are only one in a small subset of cryptographic identities, which is itself an even smaller subset of digital identities in general. I get why they've done it this way; the alternative is to write your own cryptographic protocol that nobody is using, which is a much riskier thing (speaking from experience [4]). But at the end of the day, all of Keybase hinges around using PGP (or a PGP-like approach), and I'm very skeptical that's a viable solution to the social problems we have today. [1] https://blog.cryptographyengineering.com/2014/08/13/whats-ma... [2] https://moxie.org/blog/gpg-and-me/ [3] https://www.schneier.com/blog/archives/2015/11/testing_the_u... [4] https://github.com/Muterra/doc-golix
In On Phone Numbers and Identity
I think the article does a decent job of highlighting some of (what I hear as) the primary concerns surrounding IoT, namely: 1. WiFi needs to always work 2. Internet connection needs to always work 3. Power needs to always work 4. Stability of software and firmware 5. Trustworthiness of software and firmware (including data leakage, privacy, etc) Simultaneously, though it rightly points out that IoT is still very much in its infancy, I think it misses a very important observation: there will absolutely come a day when IoT is unavoidable. Not as in you can't avoid encountering it, but as in you can't avoid owning it. There will, (I think anyways) without a doubt, be a day when devices that the average Western consumer considers necessary for everyday life -- things like refrigerators, electric meters, thermostats, and so on -- are effectiv
Read the rest
ely impossible to buy "dumb". Every analysis and meta-analysis of IoT that I've seen has been incredibly bullish on it, and I think that's an indication of how much economic incentive there is for it. Given that, I'd say automobile ECIs are the proof in the pudding for the assertion that IoT will be unavoidably ubiquitous. As an experiment, try to find a new car that you can personally can actually buy, that doesn't have a computer in it. As the median Western consumer, that's not possible. So I'm pretty convinced that for IoT, non-participation will not remain an option. So then the question is, what do we do about those 5 issues? I tend to look at stuff like this from an economic perspective; clearly device producers haven't seen enough market pressure to give a shit about any of them. Right now, the only pressure device creators are demonstrating is a profound push to get something, anything, to market. It really is an internet of shit. That being said, even the bare minimum is really hard here. You're talking about a system architecture that our existing infrastructure simply isn't cut out to handle. Think about the challenges involved in deploying a reliable authentication system to a web-scale application, and now imagine doing it in a way that can't necessarily rely upon a central server. It's far easier to just "punt" on the second half of that, assume the traditional web paradigm (trusted third party server), and call it a day. And make no mistake, for a commercial device, authentication is absolutely required, even for home WiFi network: not everyone wants every person in their house to control, for example, their locks. Or, alternatively, imagine an AirBNB host being forced to give their guests unfettered access to their IoT vibrator (yes, they exist). These edge cases are everywhere, and they make authentication of some sort or another an absolute requirement. My hope is that someone (and by someone, in all honesty I'm talking about my own project [1]) can come along and say to device producers: 1. I understand how hard it is for you to make any IoT device. 2. I'm going to make it substantially cheaper for you to do that, but... 3. The privacy and security I've baked into my system is inseparable from your economic benefit as a device producer. The idea is to evolve that into: 4. You cannot be competitive in the IoT marketplace without privacy and security. At this point, with how completely and totally horrendous the industry has been in these areas so far, I think that's the only viable way we can achieve those goals without a tremendous amount of growing pains. [1] The project is called Hypergolix, and at this point it's basically "Dropbox for Python objects, geared towards IoT, with an emphasis on social, and secured via end-to-end encryption". We're in the process of getting a private alpha shippable, to be followed soon by a public alpha. It all works, and it's all open source, but there's some necessary stuff we need to iron out in the coming weeks. Our outdated landing page is https://hypergolix.com, but a better preview of the developer experience is on our very incomplete docs page: http://pyhgx.readthedocs.io/en/latest/index.html . The whole project is backed by a crypto protocol known as Golix: https://github.com/Muterra/doc-golix
In IoT’s killer app is not home security

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.