💾 Archived View for bbs.geminispace.org › u › stack › 18549 captured on 2024-12-17 at 15:57:32. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-08-31)
-=-=-=-=-=-=-
Re: "Did you (@skyjake) consider implenting the "edit" Titan..."
I think I like this!
Jul 13 · 5 months ago
Considering how easy it is to accidentally implement sending a blank (size=0) titan request in a client, as seen in issue #671 in the lagrange github repo, I really wish a "delete" parameter would be added to titan. Just had a crash from my desktop a few minutes ago after implementing titan on my server and after opening up lagrange again, it sent a size=0 request to the server. This isn't a lagrange specific issue by any means. The only thing that saved me from dealing with a deleted file was seeing the issue yesterday and specifically disallowing size=0 requests as a result.
🕹️ skyjake [mod...] · Jul 14 at 03:32:
Yes, I do plan to implement it. Haven't quite just had the time yet.
There are a few Titan bugs that also need fixing in Lagrange and those will be addressed in the future, too.
I will say that if I were to create a gemini client with titan support that has a "reopen tabs from last sessions" feature, I would have implemented the client to have the exact same size=0 bug. This realization is why I wish there was something to differentiate size=0 from delete so I could continue to ignore size=0 and more unambiguously delete.
🚀 mbays [OP] · Jul 14 at 18:14:
@skyjake Thanks, that's good to hear. By the way, I noticed a bug in Lagrange: semicolons in the gemini url aren't percent-escaped when producing the titan url, so uploading from gemini://example.com/;size=5 results in a titan url with two size parameters, which is presumably intended to be invalid (though the spec doesn't explicitly say so).
@vi In my capsule editing script (gmEditor), I differentiated accidental size=0 deletes from intentional deletes by requiring the token set to "delete", AND the content has to be either empty or unchanged. So, if I set the token to delete a file, and then edit a different file without remembering to unset the token, it warns me that I was about to delete that file. That doesn't work if you're using tokens for their intended use-case, though...
@mbays That sounds like intended behavior unless it's sent via an input (after a ?). I think it behaves as part of the path in Gemini, although it does have special significance in Titan.
@halscode unfortunately I want to use tokens for their intended purpose in the future so I can set up a web -> titan interface in case I want/need to update my site from a public computer. Thanks for your suggestion though, now I can probably hack something together like starting the token with "delete" and making sure the token is numbers only or something like that.
@vi It could be possible, maybe, to have a secondary "delete" token in addition to the normal "edit" one, in that case. So one password to commit normal edits, the other to confirm dangerous actions? Along with other checks, like you have to also set the body to "delete this" or something.
Or just have the body checked for "delete this". I guess that works too.
My script abuses tokens pretty bad to accomplish what it does (it also has directory listings, renaming, etc). So it's not a case I would expect anything to accommodate.
Did you (@skyjake) consider implenting the "edit" Titan parameter? [gemini link] "edit" extension to Titan spec To summarise that proposal: a successful request "titan://example.org/example;edit" returns data for the user to edit, which is then submitted as a normal Titan request to the same path. I think this would make Titan editing much more usable. Without it, editing text is rather awkward. I don't see how to improve on how Bubble does it -- sending the user to a gemini page with the...