feature request: adding sourcehut support
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 (
4a62a7…. There is no way of deducing the
raw URL when given the
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.
- 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)
@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 ) !
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 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 :)
Deleting a branch is permanent. It CANNOT be undone. Continue?