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
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
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:
I have also been looking at open source decentralized identity systems like
https://github.com/uport-project/uport-connect, https://github.com/iden3 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: 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:
• 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
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