Spec writable protocol handlers

[RangerMauve]

As per @lidel's request here's an issue to track the discussion we're having on standardizing writability in IPFS protocol handlers.

The tl;dr, we've got ipfs:// and ipns:// protocol handlers in browsers like Agregore/Brave/Capyloon and most of them focus on what it means to GET some data from the protocol.

In Agregore's case, we've also had the ability to PUT or POST data to IPFS.

Initially this was done via the POST verb which would take some data, upload it to IPFS, then return the uploaded IPFS URL in the response body with a 200 status code.

Earlier this year, during the Agregore Mobile devgrant, we forked Kubo's writable gateway in order to get IPFS protocol handlers on Android with a Chromium fork. Part of this effort involved writing a spec based on Kubo's writable APIs.

The main thing that changed was that Kubo was using the 201 status code and placing the resulting CID in the Location header instead of into the response body. Initially I was aprehensive and wanted to use what we already had, but @makeworld-the-better-one convinced me using solid reasoning which I no longer remember that we should switch over.

Most recently, @fabricedesre was talking about wanting to move back to the 200+body approach for showing result URLs. It seems like this might be the apoproach he'd like to take for Capyloon which is now embedding an Iroh node which could lead to local authoring of data.

Personally, I'd like to keep the 201+location method if possible since I have code which relies on that already, but it's not a hard blocker and I'd be willing to update stuff if it means we can get writability into other browsers sooner.

This also relates to discussions we're having for ipld protocol handlers where we need to specify what an IPLD POST/PATCH should yield.

Ideally we will book a time during Labweek 2022 in Lisbon to sit down and talk about this stuff to figure out what approach we align on.