coronanet / go-coronanet Goto Github PK

Go implementation of the Corona Network

Go 100.00%

golang p2p network corona virus social distance

go-coronanet's Introduction

❗ This project is currently in the phase of figuring out the absolute minimum requirements to be useful; and creating a feasibility study (live networking code) to support those requirements. When the networking seems usable, we'll go for a interfaceable proof-of-concept, but not before. There's a concurrent mock UI experiment in rn-coronanet for the frontend side of things, which also blocks the PoC work to avoid wasting time. ❗

Interfacing

The Corona Network is a decentralized peer-to-peer social network. Instead of a cloud or backend server, this library itself is providing the APIs that thin clients (i.e. mobile user interfaces) rely on. This is done via hosting a local HTTP server that substitutes "the cloud", in reality being a gateway into a distributed world.

For a long rundown behind the model with regard to rationales, privacy concerns and security concerns, please see the go-ghostbridge project. As a quick TL;DR:

Emulating a cloud through a REST API permits us to naturally build a React Native interface on top (see rn-coronanet). Crossing over from React Native to Java to C to Go via language bindings is not sustainable.
Securing the data traffic between the React Native user interface and the REST API server is done through HTTPS via ephemeral server side SSL certificates injected directly into the client on startup.
Securing the API server from unauthenticated access is done through ephemeral API tokens injected directly into the client on startup.

You can check the latest version of the API spec through Swagger.

How to build

The Corona Network protocol is written in Go. If you want to contribute to this part of the code, you need to have a valid Go installation. We are also using Go modules, please familiarize yourself with them if they are new to you. You will also need a C compiler as certain dependencies of this project are in C.

If you can run go install in the repo root successfully, you're halfway there!

Go is one prerequisite, but it's not the only one. The main platform we are aiming for are mobile phones, so this project also needs to compile to them. We use gomobile to create the library archives that can be imported into mobile projects. You do not need to be familiar with gomobile, but you need to be able to run it.

You can install gomobile via:

$ go get -u golang.org/x/mobile/cmd/gomobile
$ go get -u golang.org/x/mobile/cmd/gobind

Android

To build the Android library archive (.aar), you need to have an Android SDK and NDK installed and the ANDROID_HOME environment variable correctly set. Please consult the Android docs if you're stuck. You might want to do it through Android Studio. We're not going to use the Android Studio at all, but it's an easy way to manage your SDKs and Android emulators.

Once Android is configured, you can build go-coronanet via:

$ gomobile bind --target android --javapkg xyz.coronanet -v -x -o coronanet.aar github.com/coronanet/go-coronanet/bridge

The first time you do the above, it will take a LOT of time. I'm not kidding, on the order of 30 minutes, as it needs to build some humongous C dependencies for 4 different architectures (x86, x86_64, arm, arm64). The good news is that subsequent builds will be fast(er).

$ ls -al | grep coronanet

-rw-r--r-- 1 karalabe karalabe 46961891 Mar 16 19:19 coronanet.aar
-rw-r--r-- 1 karalabe karalabe     6383 Mar 16 19:19 coronanet-sources.jar

Whoa, that final binary size is insane. Yes it is, but it does contain 4 architectures + debug symbols. Long term a proper build system could make things a bit more pleasant. Optimizing app size is not relevant at this phase, simplicity and portability are more useful.

iOS

iOS is not planned for the initial MVP to keep the scope smaller. A lot of prerequisite work needs to be done on supporting infra first (go-libtor, go-ghostbridge, etc), which is wasted time until it's proven to be worth it.

Contributing

This project is an experiment.

I'm very grateful for any and all contributions, but you must be aware that there are yet-unsolved challenges around running a decentralized social network. There's a fair probability that the project will flop, invest your time accordingly.

The goal of the Corona Network is to be a tiny, use-case specific decentralized social network with privacy and security above all else. If it cannot be done within these constraints, it won't be done. No cloud, no server, no tracking.

License

I don't know. This project contains a lot of my free time and a lot of my past ideas and work distilled down. I'm happy to give it all away for making the world a nicer place, but I am not willing to accept anyone making money off of it. Open to suggestions.

Until the above is figured out, contributors agree to grant their code to me (@karalabe).

go-coronanet's People

Contributors

Stargazers

Watchers

Forkers

bonedaddy karalabe daodesigner phillipahereza shehackedyou

go-coronanet's Issues

Possibility of using Ethereum for data tracking

Hi,

Here is couple of thoughts, more like questions.

It seems Ethereum to be a perfect platform for this project. Creating dApp to collect user consent using smart contract to access user location history for 14 days. The app would allow users to change (self report) on these three statuses (negative, being tested, positive) and track their location. The smart contract would execute X days after WHO (World health organisation) would declare covid19 no longer pandemic and delete related data.

I don't know whether this is possible on Ethereum and also building an Android or iOS app but the whole concept of Ethereum seems like a perfect fit. I know there are challenges, but users could sign up to get an alert if someone in the proximity tested positive. The biggest challenge is that we don't even know where are the hot spots.

I am not sure how difficult is to analyse 5 (or more) days of location data and match them against other user location data and then notify them about close proximity. Even if the alerts are not done, just displaying hotspots is worthwhile.

Mental note: Make API operations async

Most API ops only touch the local database, remote sync is independent and happens in the background. This is good, we want eventual consistency. There are a few API calls that may also be pushed into the background (gateway startup, pairing startup). Although it's simpler to block, I agree that it can be problematic on the UI side if it has to wait indefinitely. Better to return fast if things look good, and provide a way to poll subsequently for eventual failures. It avoids having to mess with timeouts on the UI.

gomobile bind takes 30 mins, binaries not cached

This is a limitation currently in gomobile golang/go#27234 (comment), I've just opened this issue so someone else won't. There's nothing to do to help in this project, we have to wait for an upstream fix.

Discussion: What are your plans with this?

First off, awesome project, and interesting way of doing it. I have a few questions regarding your intentions and whether or not we are doing redundant work.

To preface those questions, it's informative to know that I am attempting to build something in a similar vein. Specifically, it is a graphql-(server/client) web application to continue the process of the EthCC/Paris COVID case tracking spreadsheet that was started/stopped/continued by various people in the community.

My goal is to provide something that has more privacy and personal control over selective disclosure, as well as provide an anonymized dashboard for others to discover their COVID exposure risk based on the events they attended. Current WIP can be found at server and client repositories (repositories READMEs have not been updated from their boilerplate forks yet).

Note this application is optimized for getting out quickly with reasonable security/privacy, and uses Google/Twitter Sign-in (Oauth2) to facilitate quick on-boarding and verification of users. I need to map available data to a provable user so they can take over how much they'd like to disclose from now.

My questions finally:

what are you medium to long term goals of this project?
do you feel we are doing redundant work?
do you have plans for pulling (anonymized) network statistics out for public analysis consumption?
do you have a specific timeline hopefully planned? (imo, the faster the better due to the need for up to date info of pandemic)

CDN should return infinite cache headers

When returning data by hash in the CDN, we need to set infinite cache expiration. That's the sole reason why we address by hash. https://github.com/coronanet/go-coronanet/blob/master/rest/cdn.go#L45

Extract network status detection from Tor

Tor has an extensive control protocol: https://gitweb.torproject.org/torspec.git/tree/control-spec.txt . It can also (sometimes) detect if the network went down. Unfortunately I've no idea how to access that information. Would be nice to show the user if sync is not ongoing due to WiFi/cell being disabled.

Mental note: drop always-on networking

Currently tornet is built to establish a network connection to all trusted identities and maintain it. If a connection is unavailable, it tries super hard to establish one. This is wasteful: it probably uses a ton of bandwidth to keep idle Tor connections alive, and it also uses battery uselessly.

The alternative architecture is to only keep the listener always on, but not the connections. Anyone can still connect and exchange data, but if the connection goes idle for X minutes, tear it down. Whenever a node has an update for remote peers (and there is no live connection currently), we can decide how important that is:

New profile picture? Meh, sending that can wait. Queue up a low priority event and try to connect every 6 hours or so.
Have a status update (no virus change)? That's interesting, but not essential. Queue up a mid priority event and try to connect every 1 hour or so.
Newly diagnosed positive? Better get the update out asap: hammer the remote peers until you get your point across.

Multi-phase and multi-session pairing

The current pairing mechanism is deliberately simplistic. One person creates an onion address and shares it with someone else. When that other person dials the address, they do a quick credential exchange and are done. This works ok for a PoC or even prototype.

Quoting from coronanet/rn-coronanet#1 (comment):

Spent a bit of time sketching out how the more advanced pairing could work. The use cases behind the below chart were:

Support exchanging profiles before finalizing the pairing. This should help ensure that you are indeed "friending" the correct person. Note however, that the other side can easily lie and send arbitrary profiles, so this won't stop a proper attack, but it can avoid accidental pairings.
Support pairing with more than one person through a single endpoint/secret. Here the point might be that you can use the QR code to add more friends at the same time, or alternatively send a single link to multiple people and have it work. This entails making the pairing long-er lived and accepting arbitrary many joins.
You can create a pairing session, send the link over to your friend, and have them come back whenever. It doesn't have to be immediate. Note though, you must be online when they do decide to join you, since there's only direct, live communication in corona network.

Based on the above requirements, I sketched up the workflow below:

Alice creates a pairing session. This is akin to creating a temporary identity and address which can be shared with random people and then just thrown away. The backend will return the identity and address.
From this point onward Alice will do long-polls on the API, waiting for someone to come knocking on the pairing session (a blocking HTTP GET, which needs to be repeated until the session is torn down).
Alice can send this temporary address to Bob via QR code scan, URL, or whatever best works. We just need to somehow get 64 bytes to Bob.
Bob feeds this address into his Corona Network backend, which will connect to Alice through Tor and retrieve Alice's profile. Bob does not send his profile or any other data over yet. The point is that this is Alice's show (url), they need to prove themselves first.
If Bob likes the profile, he clicks "Connect" on the UI, which will send their profile + pubkeys over to Alice via Tor. Bob's HTTP request is blocking until Alice reacts too.
Alice's GET returns at this point with Bob's profile, if Alice likes it and hits Connect too, we can accept the pairing, sending over Alice's pubkey to Bob. At this point both sides have successfully paired and shared each other identities, so Corona Network can directly connect to each other and the pairing endpoint is not needed any more.
Alice might keep it alive for other people or might tear it down.

Synchronicity requirements:

Communication is always between 2 phones directly. Even if Alice shares the link on Facebook, both Alice and Bob must be online for the pairing exchange. This might need to be conveyed somehow via a UI (either tell Bob to try later, or automatically try in the background).
Since Alice doesn't know when Bob will come knocking with his profile, she needs to poll the paring endpoint with a blocking HTTP GET. We could do it with websockets too, but I feel that would be a huge complication at this point, let's not go there just yet.
After Bob accepts Alice's profile, we still need Alice to do the same. That might take long if Alice is not on her phone right now, so Bob needs to again do long polls, waiting for Alice to confirm the join.

This pairing workflow should be able to handle a lot of very complex interactions, but it is a lot more complex than the previous one.

I think I'll postpone this feature for a next phase for now, since it's not essential, rather a nice UI/UX nicety.

Configure travis

Enable this org and repo on Travis
Create a build job (and step) for linting
Create a build job for compiling and testing
Create a build job for Android binding
Add build status icon to readme

Recreating old onions on a restarted Tor hangs

This reproduces ipsn/go-libtor#20. If I do a few cycles of backend Enable/Disable/Enable, the onion creation will hang fairly fast. It kind of seems as if Tor itself loses the onion creation request, and never runs it / emits the events. Perhaps we could check how Tor 4 does this to see if it's libtor or bine. Either way, this is a nasty issue that will bite us.