Difference between ignoring and rejecting an update about braid-spec HOT 3 OPEN

Ah, that's an interesting distinction to draw attention to!

Perhaps we should say more clearly that "a client can ignore the update, and a server can reject it." I wonder what status code the server should respond with?

from braid-spec.

We also have longer-term plans to extend HTTP to allow clients to send acknowledgements back to servers. This might help with what you're doing.

Note that this work is in Level 3 of the Protocol Roadmap— it requires moving HTTP beyond a request/response client/server architecture, and generalizing it into a P2P messaging system. (I presented on this in Braid Meeting 2. Here's a shortcut to the video explaining the relevant slides 12-15.)

So whereas today's HTTP lets a client mutate a server (with acknowledgement):

Client request:

  PUT /foo             # "The state of /foo is now X

  X

Server response:

  HTTP/1.1 200 OK      # Acknowledge
  ...

And lets a server mutate a client (without acknowledgement):

Client request:

  GET /foo
  ...

Server response:

  HTTP/1.1 200 OK      # "The state of /foo is now X"

  X


                       # ...client cannot acknowledge :(

We could generalize HTTP into a more symmetric, P2P future, like this:

Peer A:

  GET /foo
  Subscribe            # Peer A asks to know about /foo from B

Peer B:

  GET /foo
  Subscribe            # Peer B asks to know about /foo from A

Peer A:

  PUT /foo             # "The state of /foo is now X"
  Version: "1"

  X

Peer B:

  ACK /foo             # HTTP/1.1 200 OK
  Version: "1"
  seen: local          # Everyone in phase 1 commit has seen this
  valid: local         # All validators in phase 1 commit has validated this

Peer A:

  ACK /foo             # HTTP/1.1 200 OK
  Version: "1"
  seen: global         # Everyone in phase 2 commit has seen this
  valid: global        # All validators in phase 2 commit has validated this

This can generalize the 200 OK message into a full 2-phase commit cycle. The cycle can tell you both whether a mutation has been validated (e.g. accepted by various authoritative servers) and whether it's been seen by all peers on the network.

I think this might help with what you're doing. Nobody has proposed a spec for it yet, but a compelling application could give us a reason to spec it up.

from braid-spec.

The idea of reversing the roles of clients and servers was also brought up this fall at IETF 118 in @bemasc's Reverse HTTP proposal (slides).

Austin Wright (@awwright) pointed out in that session that it's actually possible to do this today on HTTP, even though people don't. It wouldn't be supported in the browser fetch() API IIRC, but if your code only goes server-to-server, I think it would work.

from braid-spec.