makew0rld / gemlikes Goto Github PK

I used Lagrange, which gives you an option to write multiple lines of text, if you utilise this feature (at least on the test site), the formatting for every single comment breaks.

Examples

My entered comment, via the pop-up:

username123
Okay this is pretty epic

The outcome:

Okay (id: 4f3d18cb) @ Sat, 01 Jan 2022 09:33:10 UTC:
this is pretty epic

All comments below mine also change like so:
from

angstyteen (id: 26d71f4c) @ Fri, 10 Dec 2021 17:21:43 UTC:
an edgy comment

to

26d71f4c (id: Fri, 10 Dec 2021 17:21:43 UTC) @ an edgy comment:
username123

From gemini://gemini.circumlunar.space/~solderpunk/cornedbeef/replies-in-geminispace.gmi:

Something like Gemlikes could, of course, function for response notification as well. Instead of leaving an actual comment for the author, you just submit the URL to your response post at your own site. The backend software then fetches the provided URL (anything submitted which isn't a URL is summarily discarded), and if it's text/gemini content which contains a link back to the original post, then it is recognised as being a response (anything submitted which isn't text/gemini or which doesn't link back to some original content on the server running the backend is discarded) and the backend does something appropriate - informs the author via email, inserts a link at the bottom of the original content if it's being dynamically formatted, adds the response to an Atom feed, etc. Whatever people want to setup. Actually, I quite like this approach. Because the backend checks whatever URL it is given for a relevant link back, it is capable of figuring out all by itself which particular post is (or posts are!) being responded to, so unlike with comments there is no need for different per-post submission URLs. A single URL is sufficient for the entire site, so a link to it could easily be added to the bottom of every post by a very simple static templating system, or even by hand. We could standardise on what form that URL should take (making it a well-known endpoint, like robots.txt) to make up for the fact that text/gemini has no way to declare the URL like a HTML page would with a link (open question: how do we get this well-known URL idea working nicely with multi-user sites like pubnixes?). This would then enable automating the whole process in a sufficiently powerful bit of software, like the Live Journal client for Windows that Shufei mentioned.

Solderpunk and the mailing list haven't made up their minds about this just yet, but for now I want to encode spaces using percent signs, as it is likely to be more compatible.

Originally, using golang's QueryEscape spaces were being encoded as +. Which seemed... not wrong in the eyes of RFCs, but not workable for how many gemini servers are interested. It turns out using PathEscape will use %20, so hopefully this works well.

Source

This could should be using PathEscape and PathUnescape.

$SUBJ

When I first tried to enter a comment, I instinctively ignored the prompt saying that the first word is meant to be my nickname.

So the first word of my comment became my nickname, not an ideal result. :)

Could you, maybe, use a different delimiter, like :, and if it's not present, just call the commenter "Incognito" or something?

Mainly, allow for multiple files with the same name but different paths.

My math (and my idea of your threat model) might be wrong here, but I'm guessing that you're displaying hashed IP addresses as ids so as not to publish people's IP addresses.

For IPv4, 8 characters of a sha256 hash is probably enough to get the address back, since that's 32 bits of entropy, and IPv4 addresses only have 32 bits of entropy to start with. It'd be pretty trivial to construct a rainbow table mapping 8-char hashes back to IPv4 addresses (it'd take a few hours and about <80GB of disk space), and I'd expect it to have very very few collisions. (I can test this if you'd like.)

Truncating the hash further or salting it with some server-side secret would fix this, if it's something you think needs fixing. Using a server-side secret would also prevent people from correlating ids across multiple hosts.

Apologies if this is something you've already thought of or isn't relevant to your threat model. Hope you have a lovely day, and thank you for making this!