diff options
| author | redmatrix <redmatrix@redmatrix.me> | 2015-05-13 17:59:45 -0700 |
|---|---|---|
| committer | redmatrix <redmatrix@redmatrix.me> | 2015-05-13 17:59:45 -0700 |
| commit | 364025e550341b2922104e83d2a2fddaf4f21652 (patch) | |
| tree | 20813d8d3d5481764c0cba50aa3cb8e9a5a53033 /doc/zot.md | |
| parent | c82082d2bbb00294d62330d577dcdbc9ec6b9d1c (diff) | |
| download | volse-hubzilla-364025e550341b2922104e83d2a2fddaf4f21652.tar.gz volse-hubzilla-364025e550341b2922104e83d2a2fddaf4f21652.tar.bz2 volse-hubzilla-364025e550341b2922104e83d2a2fddaf4f21652.zip | |
remove project name dependency from most of the doc files to ease project merging, there are going to be some edge cases requiring manual tweaking as most of this was done by script.
Diffstat (limited to 'doc/zot.md')
| -rw-r--r-- | doc/zot.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/doc/zot.md b/doc/zot.md index 54af44161..f8881c551 100644 --- a/doc/zot.md +++ b/doc/zot.md @@ -57,7 +57,7 @@ In order to implement high performance communications, the data transfer format Bi-directional encryption is based on RSA 4096-bit keys expressed in DER/ASN.1 format using the PKCS#8 encoding variant, with AES-256-CBC used for block encryption of variable length or large items. -Some aspects of well known "federation protocols" (webfinger, salmon, activitystreams, portablecontacts, etc.) may be used in zot, but we are not tied to them and will not be bound by them. The Red Matrix project is attempting some rather novel developments in decentralised communications and if there is any need to diverge from such "standard protocols" we will do so without question or hesitation. +Some aspects of well known "federation protocols" (webfinger, salmon, activitystreams, portablecontacts, etc.) may be used in zot, but we are not tied to them and will not be bound by them. The $Projectname project is attempting some rather novel developments in decentralised communications and if there is any need to diverge from such "standard protocols" we will do so without question or hesitation. In order to create a globally unique ID, we will base it on a whirlpool hash of the identity URL of the origination node and a psuedo-random number, which should provide us with a 256 bit ID with an extremely low probability of collision (256 bits represents approximately 115 quattuorviginitillion or 1.16 X 10^77 unique numbers). This will be represented in communications as a base64url-encoded string. We will not depend on probabilities however and the ID must also be attached to a public key with public key cryptography used to provide an assurance of identity which has not been copied or somehow collided in whirlpool hash space. |