💾 Archived View for tilde.pink › ~maria › log › 2021-07-11_protocol_hell.gmi captured on 2023-12-28 at 16:01:15. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-01-29)

-=-=-=-=-=-=-

protocol hell

Due to a recent discussion on the mailing list [1] about malicious links and the consequences have made me re-evaluate my recent ideas about building something interactive within geminispace. Previously I thought about a standardized library (for my ruby server) that does authentication. And attached to that another library that provides a translation between mutable data in a database/storage and the gemini protocol (i.e. gemlog comments, user data, information storage).

The discussion also made me question a huge part of http (or rather the stuff I built over the past few years and whether it was a good idea to pipe literally anything through a RESTful service) and the issues it has. And how much of security lies on browser-side just to prevent something to happen to any data you own or have access to. It explains much of the 2-factor ridiculousness that happens. Sure a phone-app also can have 2-factor, but a phone is a locally controlled OS that automatically takes care of securing applications so that they can't just interact with another "just like that".

Usually when someone builds something for http that requires anyone to login, they assume it's going to be the next best facebook, and they'll have millions of accounts to deal with. In reality they are much like a forum from 20 years ago, you'll be dealing with 200 users, maybe. Sure some forums have grown, dreamincode is a good example, but many didn't grow. At the same time it's not a bad thing to have a community of 200 people that share something. Many subreddits have between 200 and 1000 people and they're quite happy and flourishing. But I am drifting and ranting now. Back to the flow.

Protocols are merely transports, a standardized technical solution to get information/data across, between 2 or more parties. (I made that one up, just now :p). And they are designed for a specific purpose. Gemini exists to be light-weight and get information from a server to a client. Very little of it is designed to send from client to server. I get that you want client certs to provide some form of authorization, maybe even authentication, but that's it. Realistically I find logging into an server through ssh, changing into the appropriate directory, having a text editor installed and then putting a gemlog entry onto a server like that quite tedious. It's better than having a huge vulnerability in your system. But it gets worse when you're thinking about uploading files, longer comments to a gemlog and similar.

I think eventually we need to have a discussion on how to approach this. Companion protocols seem to be out there (spartan for instances [2]), but somehow they need to adopt the tls client certificate scheme. This is why scp may be a bad choice, but sftp could maybe work, if you don't build it on the filesystem but plug the protocol into a database view specific to the user.

My head wants to make that work, but sftp also feels awfully complicated. Maybe I do need some external input or let this idea dwell for a while. What I'd want to reach is sort of an interactive way to modify data. And modifying data is always complicated, never easy and most definitely leads to much work. At the same time I can't exactly make an ssh login for everyone that tries to comment on a gemlog. That'd be putting too much work on the user, no one would comment on anything like that.

[1]

[2]