Recent discussions here and on the mailing list have made me wonder. If 1x INPUT is basically a way to unlock content, how do you intend to create content? Do you link up your capsule with an FTP and when you want to add or change content (may it be adding a log, a post, a response) the capsule forwards you into a specialized FTP (maybe dynamic) that shows you a read-only file based version of the content which you can append to? Are there better protocols for content? FTP feels like the obvious choice
3 years ago
@defunct Yep. I do like the idea of using tried-and-true Internet protocols instead of trying to shoehorn everything into a single set of standards, as happened with the Web. OTOH, what appeals to me about simple protocols is largely that they make it easier for a single developer to maintain a server or client implementation in their spare time, which should hinder the sort of consolidation we've seen with the Web. Leveraging INPUT may better preserve that property of Gemini.
Either way, maybe I should create some proofs-of-concept. There are many ways to pass around information, and now is probably a good time to experiment. 路 3 years ago
@lykso it's a day later. and i have come to the conclusion that gemini allows me/us to think different. currently everything that comes to mind i try to think decentralized. that opened up a lot of possibilities. distributed instead of centralized. trying to avoid the 1x INPUT stringing abuse as much as possible 路 3 years ago
Yeah, it's probably a bit much, right? But you *could* incorporate it (or TLS-authed FTP) into a client for things like uploading files... and if you wanted to reuse the same mechanism for posting text content, you could work out some standard for that. Would be efficient compared to chaining INPUTs, I think.
Although a standard for chaining INPUT requests might be the simplest solution. Could be an optional extension to the protocol if done right.
I personally wouldn't mind a client making more than one request for that purpose so long as it surfaced the multi-request nature of the action in the UI. Could even allow configurable rate-limiting.
Hmm. I'm getting ideas. 路 3 years ago
@lykso for publishing I can get on board with SCP, but when someone should add a comment on a gemlog, I doubt SCP is the way to go. 馃榿 路 3 years ago
I personally use a mix of scp and rsync over ssh for publishing. 路 3 years ago
FTP with TLS client certificate authentication seems to me like it'd be a good option. It's also possible to SSH with the same keys used by Gemini clients for identities. There's also the possibility of chaining INPUT requests and writing clients that know how to do that automatically, but that might break the "only one request per user action" ethos driving Gemini. 路 3 years ago
@warpengineer titan is interesting, but it's quite limited to editing "what you see". I'll have to ponder a little, but ultimately it's what you want. Main challenge is to add it to a client. Easiest client (for me) would be either the vim extension, or bollux (once it has TOFU) 路 3 years ago
@defunct @aka_dude what about the Titan protocol? gemini://transjovian.org/titan 路 3 years ago
gemini://transjovian.org/titan
Nope, that's all I remember 路 3 years ago
I use rsync over ssh. My capsule's content is created by a static site generator and then I just sync it to my server. 路 3 years ago
spartan looks pretty usable, if it also ran through tls. do you have additional co-protocols to recommend, @aka_dude ? 路 3 years ago
Yes, something like that. There are couple of "co-protocols" being designed, I can remember this one, for example: gemini://spartan.mozz.us/specification.gmi 路 3 years ago