feature request: adding sourcehut support #113

Open
opened 4 weeks ago by tianrui-wei · 6 comments

sourcehut sr.ht is also a git forge that is html only and is very good. It also offers a gist like service at https://paste.sr.ht/. Is there any chance to implement sourcehut support? Thanks.

sourcehut sr.ht is also a git forge that is html only and is very good. It also offers a gist like service at https://paste.sr.ht/. Is there any chance to implement sourcehut support? Thanks.
Owner

There is a way! We stumbled upon a small issue when implementing sourcehut verification a while ago and left it at that. Whoops 😥 we should resume thinking about this issue.

The issue: how to best solve the verification, since sourcehut haven't implemented a public API? We considered using that paste.sr.ht you mentioned to paste a small message with the fingerprint, as such: https://paste.sr.ht/~yarmo/4a62a787339319124eb6938fc2f74e8ae78cd402

Problem is again: no public API to get just the data. Yes, we could just get the entire HTML page and find the message but in principle, I am against parsing HTML files.

"But pastes have raw links", you might say! True. This is the raw link for the above paste: https://paste.sr.ht/blob/d361e0e90c9707be33635b4293e5af425cf96de5

A new problem arises: the identifier inside the URL is completely different (d361e0… versus 4a62a7…. There is no way of deducing the raw URL when given the HTML URL.

And providing the raw URL as proof is no good: it doesn't contain the username. Yes, we could append ?kx_username=yarmo to the raw URL or ?raw_id=d361e0… to the HTML URL (the latter having my preference) but my goodness, we're not making it easy for anyone, are we?

The last identified option, and by far the best: https://meta.sr.ht/~yarmo.pgp

Why waste times with pastes when you can directly get the key? True, openpgp keys can get freaking huge when compared to just transmitting a cute fingerprint. But still, it's a lot clearer.

Two issues:

  • keyoxide/doipjs doesn't support digesting keys as proofs yet (probaby solved in an afternoon)
  • some people couldn't upload their openpgp keys due to an upstream bug which I cannot currently find 😞 it had to do with keys that had changed their primary key and deprecated their old primary key)

The last method (using keys directly) seems best and shouldn't be hard to implement but it would suck for those unable to upload their key. So then the choice becomes: support keys+backup (2 different methods for one service provider!) or just support one of the compromises mentioned above?

That is where we left the discussion.

Kindly pinging @wiktor (he was part of that discussion at the time)

There is a way! We stumbled upon a small issue when implementing sourcehut verification a while ago and left it at that. Whoops 😥 we should resume thinking about this issue. The issue: how to best solve the verification, since sourcehut haven't implemented a public API? We considered using that paste.sr.ht you mentioned to paste a small message with the fingerprint, as such: https://paste.sr.ht/~yarmo/4a62a787339319124eb6938fc2f74e8ae78cd402 Problem is again: no public API to get just the data. Yes, we could just get the entire HTML page and find the message but in principle, I am against parsing HTML files. "But pastes have `raw` links", you might say! True. This is the raw link for the above paste: https://paste.sr.ht/blob/d361e0e90c9707be33635b4293e5af425cf96de5 A new problem arises: the identifier inside the URL is completely different (`d361e0…` versus `4a62a7…`. There is no way of deducing the `raw` URL when given the `HTML` URL. And providing the `raw` URL as proof is no good: it doesn't contain the username. Yes, we could append `?kx_username=yarmo` to the `raw` URL or `?raw_id=d361e0…` to the `HTML` URL (the latter having my preference) but my goodness, we're not making it easy for anyone, are we? The last identified option, and by far the best: https://meta.sr.ht/~yarmo.pgp Why waste times with pastes when you can directly get the key? True, openpgp keys can get freaking huge when compared to just transmitting a cute fingerprint. But still, it's a lot clearer. Two issues: - keyoxide/doipjs doesn't support digesting keys as proofs yet (probaby solved in an afternoon) - some people couldn't upload their openpgp keys due to an upstream bug which I cannot currently find 😞 it had to do with keys that had changed their primary key and deprecated their old primary key) The last method (using keys directly) seems best and shouldn't be hard to implement but it would suck for those unable to upload their key. So then the choice becomes: support keys+backup (2 different methods for one service provider!) or just support one of the compromises mentioned above? That is where we left the discussion. Kindly pinging @wiktor (he was part of that discussion at the time)
Owner

Here's the "sourcehut key upload bug" issue mentioned above: https://todo.sr.ht/~sircmpwn/meta.sr.ht/125

Here's the "sourcehut key upload bug" issue mentioned above: https://todo.sr.ht/~sircmpwn/meta.sr.ht/125
Poster

@yarmo Thank you for the detailed analysis and making this amazing website! I agree with many of your above sentiment, including no implementing html parsers etc. This does seem like more or less a showstopper. I can certainly wait for sr.ht to implement a feature that would make your end cleaner ( or if you guys thought about something very clever ) !

@yarmo Thank you for the detailed analysis and making this amazing website! I agree with many of your above sentiment, including no implementing html parsers etc. This does seem like more or less a showstopper. I can certainly wait for sr.ht to implement a feature that would make your end cleaner ( or if you guys thought about something very clever ) !
Owner

I'd still like to add sr.ht as a service provider. Just haven't found the right way to do it just yet. Need more brains on this job!

I'd still like to add sr.ht as a service provider. Just haven't found the right way to do it just yet. Need more brains on this job!
Poster

I know this may sound preposterous, but have you considered using a markdown file in a repo? The link should look something like https://git.sr.ht/~tianrui-wei/keyoxide_verify/blob/verification.md. In addition, the repo can be made unlisted.
An ugly workaround for now, sure, but it'd probably work :)

I know this may sound preposterous, but have you considered using a markdown file in a repo? The link should look something like https://git.sr.ht/~tianrui-wei/keyoxide_verify/blob/verification.md. In addition, the repo can be made unlisted. An ugly workaround for now, sure, but it'd probably work :)
Owner

Not preposterous at all, in fact, a repo is also how we verify gitea and gitlab accounts. And doesn't need to be markdown, plaintext is sufficient.

Why be so obsessed with their paste service?

This might well be the solution! I'll run a test soon

Not preposterous at all, in fact, a repo is also how we verify gitea and gitlab accounts. And doesn't need to be markdown, plaintext is sufficient. Why be so obsessed with their paste service? This might well be the solution! I'll run a test soon
yarmo added the
enhancement
label 2 weeks ago
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.