[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnu:net and IPFS: integration possible or desirable for social netwo

From: Brendan Miller
Subject: Re: gnu:net and IPFS: integration possible or desirable for social networking app development?
Date: Tue, 11 Feb 2020 18:28:12 -0800

Thanks for the great summaries and links, Martin. Looking forward to future developments with TNG, etc. And based on your comments on uPort, which make a lot of sense to me, I am going to take a closer look at Reclaim:ID.



On 2/11/20 1:46 AM, Schanzenbach, Martin wrote:

On 11. Feb 2020, at 05:59, Brendan Miller <address@hidden> wrote:

Thank you for your answers and encouragement, Martin.

As a follow up, could you summarize your key thoughts on the shortcomings of 
IPFS relative to gnu:net?
The most obvious shortcoming is that IPFS only does file-sharing via DHT.
But I guess comparing IPFS to gnunet is a bit like comparing apples to oranges. IPFS 
essentially does file-sharing. This is what the "file-sharing" 
application/service is for in gnunet.
Unfortunately, I am not an expert on this part of gnunet so maybe grothoff can 
shed some light on how they compare or what the delta actually is.

My point is: It is probably more accurate to compare GNUnet to libp2p, which is 
the stack IPFS is using.
libp2p otoh is quite monolithic and struggles with the same low-level issues as we do, 
namely transport management for connectivity (especially NAT!). We are currently trying 
to address this with our transport redesign (Project "TNG").
The other point is that libp2p/IPFS heavily rely on DNS. And the issues with 
DNS are, in our opinion, a showstopper:

And what are your concerns/reservations about uPort? How would you contrast 
their approach with that of Reclaim:ID?

Often blockchain-based self-sovereign identity systems start off with a 
blockchain and then realize that is is really bad for actually storing personal 
information as it does not scale. Then, usually, they turn to IPFS and just 
link to the data. That is until they realize that this means the data is just 
out there in the open at which point they give up on persisting the data in the 

That would be my summarization on the evolution of uPort. I have read the 
whitepapers in the past when they were still planning do add some cryptographic 
access control layer. To my knowledge, this has been scrapped and now PI is 
exchanged with relying parties ad-hoc (via the app).
This means that the relying party must store the data if any future processes 
require the data. That is not good since because of GDPR et al this data is a 
liability. That is why Identity Provider services such as Google/Facebook are 
so attractive in this regard.

re:claimID stores PI of users in the GNU Name System in a way that protects the 
information from unauthorized access. It provides cryptographic access control and an 
OpenID Connect interface. We initially used something called "Attribute-based 
Encryption" to achieve this. Currently, we only use GNS's built in encryption and 
privacy features to securely store and share identity information.
In summary: What we achieved (as opposed to uPort) is that we decentralized the 
Identity Provider service (think Google/Facebook) which allows relying parties 
(websites) to retrieve fresh user data on demand *without* having to request it 
again from the user or store it locally. (as long as they are authorized)


Much appreciated!

And do I look forward to staying in touch.



On 2/10/20 12:04 AM, Schanzenbach, Martin wrote:
Hi Brendan!

thank you for your interest in GNUnet.
In general I think you have the right ideas :)

One thing to node in general is that most of the technologies you are 
significantly more
mature from a users perspective _because_ they do not address the whole stack.
IPFS otoh does a lot of things right, some not so well (naming) and other 
things not at all ;)

I could rant about uPort et al all day but let me focus on your questions for 
now :D

On 10. Feb 2020, at 03:03, Brendan Miller <address@hidden> wrote:

Hi, all. I am a web/web3 developer interested in helping to build open source, 
private, decentralized alternatives to social platforms like Facebook, WeChat, 
etc. I am coming from a technical starting point of IPFS, Ethereum blockchain 
and secret contract platforms like Enigma and Oasis, but I am not yet committed 
to a certain tech stack, and I certainly don't want to reinvent any wheels.

I am starting to recognize that some of the privacy protecting architecture I 
was envisioning layering on top of IPFS, for example, was not really at the 
right networking layer - it should be handled at a lower layer. As a part of 
that realization, I have recently found gnu:net, reclaim:id and related 
projects and am excited about the attention you give these layers.

I was imagining that the apps I would like to build would be mobile apps so 
that they could be accessible to the majority of users, be able to protect the 
user's private keys, and also be able to run in a fully decentralized/mesh 
situation when needed/desired.

Textile ( on top of IPFS interests me because they are open 
source, and provide useful functionalities that I would need. And they are set 
up for mobile apps. As an example of whatH can be done with Textile, you can 
take a look at this functional photo sharing/messaging React Native mobile app:

I have also been looking at open source decentralized identity systems like, and

Fundamentally, I am an app developer, but one who cares about ensuring 
decentralization and privacy by default, with the ability to safely share 
identity claims, user groups and content/media/files when desired. My goal is 
to build on top of as much existing, reliable, maintained open source code as 
possible so we can show users the full functionality they expect from existing 
social networking apps to make it attractive to switch over.

My questions are these:

        • Does anything similar to Textile exist in the gnu:net ecosystem?
No. But I guess it could be built on top of the "fs" (file sharing) service. I 
cannot say I am an expert on this tool.

        • Can gnu:net practically operate in a battery-sane manner on Android 
and iOS devices? Is there a guide for how to do this? What tradeoffs are 
necessary to operate on mobile?
Currently, it is not advised to do that. More than battery, we currently worry 
about data usage. We are currently rewriting
our transport service to address this (so that a mobile node can indicate that 
it will not provide as much to the network).
The bigger problem is probably that GNUnet currently does not run on iOS or 
Android. We currently do not have developers familiar
enough with porting/App development to try.

        • IPFS uses a modular infrastructure. Would it be possible to swap out 
some lower-level networking layers of IPFS with gnu:net modules for greater 
privacy? (Reference:
I think the only part in IPFS that may be swapped out easily is the name 
system. It could use GNS.
They also seem to oppose the use of our DHT:

        • Would it be possible to somehow make the gnu:net and IPFS ecosystems 
operationally compatible, perhaps using gateways/bridges, so that their 
content/data can be shared? If so, how hard would that be?
I guess you would reimplement the "merkledag" (Section 3.4) and "Application Data 
Structure" (Section 4.) in GNUnet. Then those use
the "file sharing" service instead of the IPFS stack.
At this point you have an IPFS on top of GNUnet, but it is not yet connected to the 
"other" IPFS.
So now you need to have some peers that function as a bridge and translate 
between the IPFS and GNUnet network.
You would probably bridge at the application layer.
There _may_ be problems such as duplicate data. So maybe you have to do some 
namespacing when referring to data (in the other network).

Thanks for any insights into these questions, and for your work on gnu:net.
I hope I have answered your questions, feel free to ask more and stay in 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]