goldcollection
/
muwire
mirror of https://github.com/zlatinb/muwire
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Get rid of separate public key for personas, use the PSK in the Destination instead. Do not encrypt GET and POST method URLs

pull/4/head
Zlatin Balevsky 2018-11-15 19:30:44 +00:00
parent 9808856478
commit 8e1727fa4d
3 changed files with 13 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
doc/design.md
View File

@ -45,7 +45,7 @@ Unlike Gnutella, MuWire nodes send search results over a streaming I2P connectio
### File transfer
Files are transferred over HTTP1.1 protocol with some custom headers added for download mesh management. Files are requested with a GET request which includes the infohash of the file in the URL. The URL itself is encrypted with the public key of the target persona to prevent carpet-bombing the network with GET requests.
Files are transferred over HTTP1.1 protocol with some custom headers added for download mesh management. Files are requested with a GET request which includes the infohash of the file in the URL.
### Mesh management
@ -55,6 +55,3 @@ Download mesh management is identical to Gnutella, except instead of ip addresse
Nodes will periodically ping a pre-defined Destination for a JSON document containing the infohash of a new binary update package using signed datagrams. If the response indicates a newer version is available, the node will issue an automatic search for that infohash and download it, then prompt the user to install the update.
### Web Of Trust
Users may choose to "Trust" or "Blacklist" Destinations that return search results. This trust is local to the user, but it can be shared with others. Each user is assigned a perona which is returned together with search results and when displayed in the UI. For more information see the web-of-trust document.

7
doc/web-of-trust.md
View File

@ -4,12 +4,13 @@ The Gnutella protocol is very efficient at keyword search, but it is very expose
### Definition of a Persona
MuWire assumes that each human user is going to have a single persona. A persona consists of the following three items:
MuWire assumes that each human user is going to have a single persona. A persona consists of the following two items:
* An I2P destination - this is the destination where the MuWire node is listening for incoming requests.
* A human-readable nickname
* A public key
For UI purposes, the persona will be displayed as the human-readable nickname plus underscore followed by the first 32 bytes of the b32 I2P address derived from the b64 destination. The intention is to make it easier for users to differentiate between personas, but at the same to prevent spoofing of personas through mass generation of I2P destinations.
The nickname and the I2P destination are signed by the signing key which is part of the destination. This is to provide assurance that the owner of the private key is the one who has chosen the nickname.
For UI purposes, the persona will be displayed as the human-readable nickname plus '@' followed by the first 32 bytes of the b32 I2P address derived from the b64 destination. The intention is to make it easier for users to differentiate between personas, but at the same to prevent spoofing of personas through mass generation of I2P destinations.
### Trusting other personas

18
doc/wire-protocol.md
View File

@ -4,7 +4,7 @@ The MuWire protocol operates over a TCP-like streaming layer offered by the I2P
## Handshake
A connection begins with the word "MuWire" followed by a space and one of the following words: "leaf", "peer" or "results", depending on whether Alice is in a leaf, ultrapeer or responder role. This allows Bob to immediately drop the connection without allocating any more resources.
A connection begins with the word "MuWire" followed by a space and one of the following words: "leaf", "peer" or "results", depending on whether Alice is in a leaf, ultrapeer or responder role. This allows Bob to immediately drop the connection without allocating any more resources.
If Bob is an ultrapeer he responds to the handshake by either accepting it or rejecting it and optionally suggesting other ultrapeers to connect to.
@ -43,10 +43,8 @@ A persona is represented as a blob with the following format:
```
byte 0: unsigned version number of the format. Currently fixed at 1.
bytes 1 to N: nickname of the persona in internationalized format
bytes N+1 and N+2: unsigned length of the I2P destination of the persona
bytes N+3 to N+M: the I2P destination of the persona
bytes N+M+1 to N+M+O: public key of the persona (length of public key TBD)
bytes N+M+O+1 to N+M+O+P: signature of bytes 0 to N+M+O (length TBD)
bytes N+1 to M: the I2P destination of the persona
bytes M+1 to O: signature of bytes 0 to M (length TBD)
```
## Certificate wire format
(See the "web-of-trust" document for the definition of a MuWire certificate)
@ -161,7 +159,7 @@ This message starts with two unsigned bytes indicating the number of patches inc
### Search results - any node to any node
Search results are sent through and HTTP POST method from the responder to the originator of the query. The URL is the UUID of the search that prompted ther response, encrypted with the public key of the originating persona. This connection is uncompressed. The first thing sent on it is the persona of the responder in binary. After that follows a stream containing JSON messages prefixed by two unsigned bytes indicating the length of each message. The format is the following:
Search results are sent through and HTTP POST method from the responder to the originator of the query. The URL is the UUID of the search that prompted ther response. This connection is uncompressed. The first thing sent on it is the persona of the responder in binary. After that follows a stream containing JSON messages prefixed by two unsigned bytes indicating the length of each message. The format is the following:
```
{
@ -172,7 +170,7 @@ Search results are sent through and HTTP POST method from the responder to the o
size: 12345,
pieceSize: 17,
hashList: [ "asdfasdf...", "asdfasdf...", ... ]
altlocs: [ "persona.1", "persona.2", ... ]
altlocs: [ "persona.1.b64", "persona.2.b64", ... ]
}
```
* The "hashList" list contains the list of hashes that correspond to the pieces of the file
@ -182,16 +180,16 @@ Search results are sent through and HTTP POST method from the responder to the o
### "Who do you trust" query - any node to any node
(See the "web-of-trust" document for more info on this query)
This is a GET request with the URL "/who-do-you-trust" encrypted with the target node's persona key. The response is a binary stream of persona details.
This is a GET request with the URL "/who-do-you-trust". The response is a binary stream of persona details.
### "Who trusts you" query - any node to any node
(See the "web-of-trust" document for more info on this query)
This is a GET request with the URL "/who-trusts-you" encrypted with the target node's persona key. The response is a binary stream of certificate details.
This is a GET request with the URL "/who-trusts-you". The response is a binary stream of certificate details.
### "Browse host" query - any node to any node
This is a GET request with the URL "/browse" encrypted with the target node's persona key. The response is a stream with the same format as the body of the search results POST method above.
This is a GET request with the URL "/browse". The response is a stream with the same format as the body of the search results POST method above.
# HostCache protocol