Preserving relative IRIs in RDF representations in server responses

I open this issue to capture implementation feedback from @NoelDeMartin after his presentation at Local-First online meetup: https://www.youtube.com/live/GDQMLt3oqio
Based on the following matrix conversation

To my understanding some of Noel's implementation depends on Solid Server using relative IRIs in the reponses. Specificaly with BASE being set to the response location (Response.url).
Currently as far as I can tell Solid Protocol doesn't offer such guarantees, for example (PREFIX doesn't matter, just the BASE):

App X

PUT /test HTTP/1.1
Host: pod.example
Content-Type: text/turtle

PREFIX ex: <https://ns.example/>
<> a ex:Test .

Server for examle stores it in internal quadstore and later:

App X

GET /test HTTP/1.1
Host: pod.example
Content-Type: text/turtle

<https://pod.example/test> a <https://ns.example/Test> .

Even if server would simply save verbatim turtle to filesystem or document oriented database, we could still insert in between another app making an update:

App Y

PUT /test HTTP/1.1
Host: pod.example
Content-Type: text/turtle

PREFIX ex: <https://ns.example/>
<https://pod.example/test> a ex:Test .

So both Server and Client could currently lead to a data that was using relative IRIs in specific serialization, to endup with serialization using absolute IRIs.

I would like to reference https://www.w3.org/TR/rdf11-concepts/#section-IRIs

Relative IRIs: Some concrete RDF syntaxes permit relative IRIs as a convenient shorthand that allows authoring of documents independently from their final publishing location. Relative IRIs must be resolved against a base IRI to make them absolute. Therefore, the RDF graph serialized in such syntaxes is well-defined only if a base IRI can be established [RFC3986].

If we want to provide some guarantees that in RDF serializations that server responds with, it uses relative urls with BASE set to the response location/url. I think something in those lines would be requried:

For text/turtle it would need to serialize it with BASE and remove the BASE from the content.
For application/ld+json it would need to compact the response with @context using @base, in that case I don't think the context could be removed so possibly it can't even be supported for JSON-LD. Maybe if @context only sets the @base it can be removed and consumer only needs to make sure to provide @base to the parser. Someone may need to check it.

Personally I only use full IRIs so this doesn't really impact my work, I'm capturing it as part of Solid CG responsibility of gathering feedback from implementers.

The issue names no repository files or tests. Start by reviewing the Solid Protocol requirements alongside RDF 1.1 Concepts, the Turtle and JSON-LD serialization cases, and the linked implementation discussion. Done would require a decided, testable specification for whether responses preserve relative IRIs against Response.url.