Re: gnu:net and IPFS: integration possible or desirable for social networking app development?

[Schanzenbach, Martin]

Hi,

> 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:

https://git.gnunet.org/gnunet-videos-2019.git/plain/ICANN66/GNU_Name_System_-_2019_ICANN66__Martin_Schanzenbach.webm
https://git.gnunet.org/gnunet-videos-2019.git/plain/IETF104/GNU_Name_System_-_2019_Edition_IETF104__Christian_Grothoff.webm

> 
> 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 
network.

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)

BR
Martin


> Much appreciated!
> 
> And do I look forward to staying in touch.
> 
> Best,
> 
> Brendan
> 
> 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 (https://textile.io/) 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: https://github.com/textileio/photos
>>> 
>>> I have also been looking at open source decentralized identity systems like 
>>> https://github.com/uport-project/uport-connect, https://github.com/iden3 
>>> and https://github.com/jonnycrunch/ipid.
>>> 
>>> 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: 
>>> https://github.com/ipfs/specs/blob/master/ARCHITECTURE.md)
>> 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: 
>> https://discuss.ipfs.io/t/consider-r5n-dht-rathar-than-kadmelia/6691
>> 
>>>     • 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 
>> contact.
>> 
>> TY
>> Martin
>> 
>>> Best,
>>> 
>>> Brendan
>>> 
>>> https://www.linkedin.com/in/brendanmiller/
>>>