-
Notifications
You must be signed in to change notification settings - Fork 0
/
RFC
185 lines (120 loc) · 6.65 KB
/
RFC
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
L. Brooks
Request for Comments:
Obsoletes:
Category: Standards Track
Febuary 2016
Distributed Hypertext Transfer Protocol
Hypermedia caching as an additional WebRTC use case
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) Luke Brooks (2016). All Rights Reserved.
Abstract
Distributed HTTP is a form of HTTP mediated by caching proxies
that speak a common protocol to one another. This is
implemented through the relationships between domains, resources
and revisions.
Instances of compatible proxies respect a routing topology based
on Kademlia with free node ID generation seeded by the nodes' IP
address, port number and public RSA key.
All revision objects have an associated SHA1 hash to be used as
their identifier.
Stored resources may optionally be made public where their original
URL is SHA1 hashed and used as a Kademlia node ID. The corresponding
node is then searched for and informed that you are willing and able
to serve data corresponding to the content hash for the resource
in question.
Distributed trust computation is discussed further on.
Brooks, et al. Standards Track [Page 1]
RFC ____ DHTTP/0.1 Febuary 2016
1 Introduction ...................................................7
2 Routing Topology ...............................................7
3 Collaborative Editing ..........................................7
4 Distributed Trust ..............................................7
5 Attribution and Licensing ......................................7
Table of Contents
1 Introduction
1.1 Purpose
Distributed HTTP is set of fundamental principles for peer-to-peer
networks sharing Hyptermedia resources amongst nodes engaging in
shared overlay network namespaces, making HTTP resistant to server
downtime, domain name forfeiture and optionally, dedicated servers.
1.2 Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [34].
An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocols it
implements. An implementation that satisfies all the MUST or REQUIRED
level and all the SHOULD level requirements for its protocols is said
to be "unconditionally compliant"; one that satisfies all the MUST
level requirements but not all the SHOULD level requirements for its
protocols is said to be "conditionally compliant."
1.3 Terminology
This specification uses a number of terms to refer to the roles
played by participants in, and objects of, Distributed HTTP networks.
instance
An instance of a distributed HTTP proxy that implements
and supports this protocol.
peer node
The local perspective of a remote instance.
overlay network
A routing table containing references to known peer nodes.
message
The basic unit of distributed HTTP communication which may consist
of references to known peer nodes in order to passively reinforce
the routing topology.
RPC
Remote Procedure Call.
A local procedure called from a remote instance.
node ID
A 160-bit binary value.
Free node ID generation MUST be limited to the SHA1 hash of an
instances' public IP address, port number and public RSA
key. This prevents users from obtaining node IDs that can permit
the collection of valuable usage data for a URL of interest.
APPEND
The APPEND RPC uses the SHA1 hash of a URL or hypermedia object
and uses this as a node ID, contacting the node in question or
neighbouring nodes and appending a reference to our own instance,
indicating we will serve data that corresponds to the given
content hash.
FIND
FIND procedure calls indicate lookups for a given SHA1 hash by
using it as a node ID and asking peers
2 Routing Topology
2.1 Overlay networks as described by Kademlia (2002)
https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf
Secure Node ID generation
Kademlia via JSON over HTTP/1.1
Kademlia with ProtoBufs over HTTP/2 or QUIC. Bytestreams.
Routing table reinforcement
Multiple routing tables
Trust-based table selection
3 Collaborative Editing
RPC_EDIT
fragment, document
tree reintegration
Inter-instance RPC_EDIT
Edited revisions in overlay networks
4 Distributed Trust
4.1
www.cc.gatech.edu/~lingliu/papers/2012/XinxinFan-EigenTrust++.pdf
Preemptively detecting malicious peers with P and EP.
5 Attribution and Licensing
5.1 Introducing the license attribute
"Information wants to be free. Information also wants to be
expensive." -- Stewart Brand
A REQUIRED safeguard for protecting the livelihoods of economic
producers is the recognition of a "license" attribute when
referencing copywritten hypermedia objects.
E.G.
<img src="/portfolio_item.png" license="Copyright Site. Owner 2016" />
SHALL cause instances to either omit retrieval or demarcate the object
as unpublicizable to network peers, whereas
<img src="/vacation_photo.png" license="CC BY" />
SHALL NOT.