You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just recently discovered @Lukasa's Peer to Peer Extension to HTTP while developing a security protocol using HTTPbis' Signing HTTP Messages RFC. This allows the web we have known since its inception, based on fixed roles of client and server, to change in a dialogical manner.
It turns out this feature is very useful, opening the promise of Authentication and Authorization to happen over 1 connection, as I argue in this HttpSig specification.
Furthermore, P2P opens up some really interesting insights from philosophy. Recent work on Logic has highlighted The dialogical roots of deduction. Closer to issues of interest to Web Technical Architecture Group are well known concepts from the Philosophy of language on indexicals.
Take indexicals. Because P2P HTTP allows both sides of a connection to take on the roles of client and server, relative URLs passed in headers could refer to resources on the client or on the serve. That is just as in a conversation between peers where each can utter the indexicals "I" to refer to a different person. If Tim asks me where my keys are I can tell him "in my right pocket". Then he could answer "please give me your keys in your right pocket".
So let us say that we have two devices Phone and Pod. Phone opens a connection to Pod to ask for a resource </personal/bankId> . Said by Phone, that refers to a resource on Pod. Now Pod may answer "401 Who are you?" And Phone may answer either by pointing to a resource on the web, or one on Pod, but it may also point to one in its own storage. For, with P2P HTTP, Pod can turn around and GET that on the same connection too. So we now can distinguish two types of relative URLs, when Phone is speaking:
</auth/Cert1> for a resource on the Pod
>/auth/Cert1< for a resource on the Phone
The string /auth/Cert1 is the same in both, so the two types of angle brackets are needed to tell us which side of the connection is referred to at that stage of the conversation.
Interestingly these could leak into documents, if these end up being built up along a conversation between two parties that only know each other by the fact that they are each on the other side of a secure connection.
The P2P extension to HTTP could help make real how "client" and "server" are roles that can be exchanged during a conversation, leading us to think of the World more dialogically.
I would be interested to know how that then extends to HTTP/3 whose efficiency we could very much do with.
But it also opens the question whether it could address issue 12: WebSocket and REST opened by @swickr a few years ago on the web arch github repo, as the following thought experiment shows.
The text was updated successfully, but these errors were encountered:
I just recently discovered @Lukasa's Peer to Peer Extension to HTTP while developing a security protocol using HTTPbis' Signing HTTP Messages RFC. This allows the web we have known since its inception, based on fixed roles of client and server, to change in a dialogical manner.
It turns out this feature is very useful, opening the promise of Authentication and Authorization to happen over 1 connection, as I argue in this HttpSig specification.
Furthermore, P2P opens up some really interesting insights from philosophy. Recent work on Logic has highlighted The dialogical roots of deduction. Closer to issues of interest to Web Technical Architecture Group are well known concepts from the Philosophy of language on indexicals.
Take indexicals. Because P2P HTTP allows both sides of a connection to take on the roles of client and server, relative URLs passed in headers could refer to resources on the client or on the serve. That is just as in a conversation between peers where each can utter the indexicals "I" to refer to a different person. If Tim asks me where my keys are I can tell him "in my right pocket". Then he could answer "please give me your keys in your right pocket".
So let us say that we have two devices Phone and Pod. Phone opens a connection to Pod to ask for a resource
</personal/bankId>
. Said by Phone, that refers to a resource on Pod. Now Pod may answer "401 Who are you?" And Phone may answer either by pointing to a resource on the web, or one on Pod, but it may also point to one in its own storage. For, with P2P HTTP, Pod can turn around and GET that on the same connection too. So we now can distinguish two types of relative URLs, when Phone is speaking:</auth/Cert1>
for a resource on the Pod>/auth/Cert1<
for a resource on the PhoneThe string
/auth/Cert1
is the same in both, so the two types of angle brackets are needed to tell us which side of the connection is referred to at that stage of the conversation.Interestingly these could leak into documents, if these end up being built up along a conversation between two parties that only know each other by the fact that they are each on the other side of a secure connection.
The P2P extension to HTTP could help make real how "client" and "server" are roles that can be exchanged during a conversation, leading us to think of the World more dialogically.
I would be interested to know how that then extends to HTTP/3 whose efficiency we could very much do with.
But it also opens the question whether it could address issue 12: WebSocket and REST opened by @swickr a few years ago on the web arch github repo, as the following thought experiment shows.
The text was updated successfully, but these errors were encountered: