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

Security & PrivacyFinance & Commerce
Explore on GitHubRead Hacker News discussions
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

4 sources
nbadg·Aug 12, 2015
I'm actively developing a network protocol for secure end-to-end datastreams between any objects connected to the same physical network. It's conceptually reminiscent of email in that you register an address and then use it on any provider, can have multiple addresses per machine or access the same address on multiple machines, etc. I've been building off work by IPFS (http://ipfs.io/), with an eye on future compatibility with distributed systems like ethereum. I just finished a reasonably decent draft of the whitepaper (https://github.com/Muterra/doc-muse/blob/master/whitepaper.m...) and would love some feedback. The yellowpaper explains much more detailed implementation, but is in a pretty rough state (absolutely not even draft quality: https://github.com/Muterra/doc-muse/blob/master/yellowpaper....) Cheers and thanks!
In Muse protocol: encrypted bytestream “email” for IoT (and beyond)
nbadg·Aug 3, 2015
That effectively implement storage+sharing+identity? Not that I'm aware of, which is why I'm working on one (https://github.com/Muterra/doc-muse). Plenty of things try and tackle one or two of those but I've never seen anything address all three. I would really, really like to know if one exists so I can pick it apart and learn from it. A big part of the difficulty is that you truly can't be everything for everyone, but you really need to be something for anyone. If you approach it as a distributed social networking problem (which is most of what I've seen) then you're really missing the indescribably large forest for one specific tree. The blackbox I've focused on for this protocol is (arbitrary insecure physical bytestream in) -> [box] -> (arbitrary private, authenticated, integrity-verified bytestream out). We use networks to communica
Read the rest
te between persons/services/things, not between IP addresses -- the right place to address the problem is between network and application.
In The Web We Have to Save
nbadg·Aug 3, 2015
I don't agree that email is decentralized.[1] It's interoperable and universal, but that's not the same thing. You can use a single address for mail from arbitrary sources, and all email addresses, regardless of client or mailserver, can talk to each other. But once you've chosen a mailserver for any given address, you've put all of your eggs in that one basket. Now, it's easier to switch clients, but let's be realistic, when's the last time you did that? And both the list of popular mailservers (http://www.mailradar.com/mailstat/) and clients (https://emailclientmarketshare.com/) is quite short. Honest feedback: as far as I can tell from a quick onceover, qbix is just an aggregator for existing services. That doesn't really solve the problem, and arguably, by positioning yourself as a single point of failure for negotiations between diff
Read the rest
erent APIs (facebook, email, sms, etc), you're actually creating a system that is substantially more centralized, not less. And you're covered by a patent (or at least an application), so potential competitors can't interoperate without a licensing agreement. If you're trying to be a decentralized, universal platform, you've just shot yourself in the foot. Disclaimer: I'm working on a similar problem, but I'm doing it as an abstraction layer between transport (TCP/IP, bluetooth mesh, anything with a reliable bytestream) and application. That allows you to do some really cool things, like communicating between people (or services or whatever), regardless of device or physical network topology. https://github.com/Muterra/doc-muse [1] That isn't necessarily a bad thing, and I think that email is a great example of a very successful hybrid (both centralized and decentralized) system -- it allows users to choose between centralized providers with minimal switching cost. Centralization with zero node lock isn't necessarily bad.
In The Web We Have to Save

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.