💾 Archived View for bbs.geminispace.org › s › Gemini › 2166 captured on 2023-07-10 at 13:47:17. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
I reconsidered my earlier ideas about editable gemini pages based on @skyjake's feedback. Now I'm thinking that a response code of "21" (Success+Editable) could indicate that the response body could be edited and uploaded via the titan protocol at the same URI used to make the request.
This allows a client to know when a page can be loaded into a large editor window and uploaded as one body using the titan protocol. A response of "21" can be treated the same as a response of "20" by clients that don't want to do anything special (which is aligned with the way digit codes are described in the gemini spec).
I just realized that I really don't understand the handoff between gemini and titan when I use Lagrange with this BBS and click on "Edit with Titan" on a non-raw page. I'm thinking it would be good to have a rough idea of where the client+server user interface is going before I propose a new response code. I'm assuming it would be helpful to tag a page with a "titan editable" property, but I realize I don't have a clear picture of how the BBS is using titan.
2023-06-18 · 3 weeks ago
I'm pretty sure the window to add new status codes to the Gemini spec has closed, unless Solderpunk suddenly gets super interested in editable resources. Technically, clients are supposed to only look at the first digit of the code in case of an unfamiliar status, but even so a server should only return statuses in the spec.
Using status codes would require a roundtrip to the server before a client realizes that a resource can be edited, a bit like with input prompts. Instead of that, I would prefer that editable resources have a "titan://" link on the page, so the client can just pop up the upload UI without asking for further information.
The way it works with Bubble currently is that most Titan links are sent to the client via a status 30 redirect, because the Titan actions are mostly hidden behind shortcut commands. A more Titan-focused application could just include a bunch of "titan://" links on the page for editing specific resources.
The problem with that approach is that, as mentioned before, the client doesn't have the previous raw contents of the resource at hand when it opens a Titan URL, which is why it would make sense to define an actual protocol for a client to first receive the contents and then upload them back.
One possibility would be to use the Titan token parameter to define a special keyword that tells the server to respond with the current raw contents so that the client can populate its upload UI with it. This would require a change in the Titan specification to reserve that keyword, but that might be possible I think.
An editable URL would then look like:
titan://hostname.tld/my/resource;token=GET
@skyjake For now I'm still in brainstorming mode, so all things are possible. I'm still trying to understand the problem. My reading of the Titan spec is that it does NOT provide read access to anything. So in my mind, you can't use titan to edit anything, only write it. If you only had a titan client that didn't speak gemini, you couldn't "edit" anything. You could only write resources.
So my mental model is this: gemini is for reading a resource and titan is for writing a resource. Now the problem is how to hook them together. The titan spec implies that a valid titan resource can also be read by using the gemini protocol with the same URL. The titan spec references the gemini spec.
Currently the gemini spec doesn't refer to the titan spec (which is for good and appropriate reasons). But my gut tells me you can't make the titan and gemini protocols hand off between each other cleanly without the gemini protocol knowing about the titan protocol in some small way.
If we extend the titan protocol with a GET mode, then we now have two protocols can can browse the gemini web right? Could I now use a titan-only client for everything?
Here is one of the things that confuses me in Lagrange. At certain points in the edit flow I end up with a Lagrange window that has a titan: URL in the URL bar at the top of the window. But titan wasn't used to load the page. That's confusing to me.
Okay, here's another confusing thing. If titan is technically write-only, then what does a titan link in a gemtext page even mean? Does either protocol explicitly say what's supposed to happen when a user clicks a titan link in a client? Presumably when you select any protocol link that is an upload-only protocol the client should prompt you for what to upload in some way. In gemini: you don't know whether it's an upload-only link until you fetch it and look at the response. But in titan: you know from the beginning it's upload-only.
In the Titan protocol description, there is a section called "Peculiarities of this wiki" that describes the convention for using "raw" pages. But that section doesn't explain how the client is supposed to know which pages are "raw" pages and which pages aren't. It seems clear that this section was not intended to be part of the titan protocol itself, but just an example of how to use.
You should think of Titan as fully equivalent to Gemini, but when making a request, the client gets to append a payload as well.
So Titan can totally be used for reading resources, too. I think the only missing part here is to instruct the client exactly what happens when opening a titan:// link. Currently the only defined behavior is to ask the user to provide the payload (with token & MIME) and then submit the request.
So what we need is for the client to know that it can just submit the titan:// request as is first without a payload, then receive the data from the server, and finally redo the request with the payload.
— Let the record show that this discussion was continued in the fediverse...