consensus
[Top][All Lists]
Advanced

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

[GNU/consensus] zeronet as cms


From: marc
Subject: [GNU/consensus] zeronet as cms
Date: Fri, 15 Jul 2016 13:52:11 +0100
User-agent: Roundcube Webmail/1.1.2

I am forwarding below a message. Any feedback, hack, crack, etc welcome.

-----


This is a report about how we can proceed to deploy a client side cms based on zeronet.

The design of zeronet is very closely resembling our idea of cryptospheres together with a p2p distribution system. There are some problems though:

**Network side vs Client side**

We will make a distinction that doesn't exist in zeronet between Network Side (the python side) and Client Side (the javascript side).

On ZeroNet there is just python side, and the client side just commands the python api and provides gui.

By introducing this distinction we can have zeronet nodes supporting many users instead of current model of just one.

This way a globally accessible deployment like https://zero.irka.io can be used by different users with their own identity and data. Right now, everyone accessing zero.irka will be using the node identity and will share a single mailbox etc.

**No client (js) side signing**

Reading the ZeroFrame API [1] we can see the private keys always have to be provided to the backend, which precludes client side users, even though they would be possible given the architecture.

Thus, our goal can be to allow such client side users, the main tool for this can be a (possibly) small zeronet modification, adding a ZeroFrame API function to sign sites on the client side. More generally, all functions have to be doable from js using the node as a proxy to the zeronet. The javascript side would then become a **ZeroNet LightClient**

**Generating certificates for client side keys**

There seems to be a special mechanism [2] to allow users to host their own data on zeronet sites, this is so, because as zeronet specs, only the owner can add new files to the main content.json (maybe there is some other way around it but have not found it).

Following the tutorial there seems to be a way of wildcard accepting users by using a certificate authority. To this effect, zeroid is used in general, but it doesn't support signing certs for javascript owned keys.

There may be a way around this, but needs to be investigated, otherwise we can clone zeroid but allow only client keys, this can also have the benefit of allowing only client side users, not network side. Once we have certificates for client side js keys, we can likely setup the ACL for multiuser client side.

**Network side firewalling**

The network identity doesn't want it's light clients acting on its behalf, so all functionality that would sign with node identity has to be firewalled on public facing nodes.

Maybe this is limited by the fact that some operations need private key provided by the user, but seems like user content is not like this... we need to be sure otherwise the node will be easily compromised.

[1] https://zeronet.readthedocs.io/en/latest/site_development/zeroframe_api_reference/

[2] https://zero.irka.io/Blog.ZeroNetwork.bit/?Post:46:ZeroNet+site+development+tutorial+2



reply via email to

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