[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNU/consensus] zeronet as cms,
marc <=