Two things:

1. This seems to be a misunderstanding. The URL has always been the internal storage URL, it is not meant for outside use. AFAIU the public URL of an artifact is predetermined (https://git.sr.ht/~<user>/<repo>/refs/download/<tag>/<filename>), hence there is no need to return it (besides potentially convenience?). Admittedly, this is documented neither for the old nor the new API, so I'll submit a patch at least for the new API to do so.

2. That said, this is indeed currently broken in GraphQL, because unlike in the old API, the GraphQL resolver does not add artifacts/<user>/<repo> to the prefix. I'll submit a patch for that as well, but it's unfortunately not quite trivial, so I'll need some time to prepare a test environment with repos and artifacts.

• user(id: Int!) should be removed
• mailingList(id: Int!) should be removed
• email(id: Int!) should be removed, but message(messageID: String!) must be fixed first (angle brackets and potential comments removed from database)
• patchset(id: Int!) should be replaced by patchset(messageID: String!)

i could take a look at this if you can maybe provide a bit more context?

This was fixed in https://git.sr.ht/~sircmpwn/meta.sr.ht/commit/2fa9543 and can be closed.

So yeah, sorry, but I cannot reproduce this. There must have been some circumstance leading to this that got lost in translation. We should probably close this ticket and create a new one with new information if this ever happens again.

So, this was fixed in a different place in meta.sr.ht before: https://git.sr.ht/~sircmpwn/meta.sr.ht/commit/6a64ac6a, but was missed elsewhere: https://git.sr.ht/~sircmpwn/meta.sr.ht/tree/master/item/api/graph/schema.resolvers.go#L737

Which begs the question: should we maybe put s/t in the middleware that always strips the port? No assumptions can be made about it being present, anyways.

WDYT, ~sircmpwn?

I'll look into this, the cause is obvious, not sure how easy the fix is, though

Proposed plan:

Keys can have an expiration date or not -> DB column would be nullable "timestamp without time zone".

Default would be NULL for all existing keys, which would then mean both "does not expire" and "not known if it expires".

Question: how to migrate existing keys? I see two options:

1. Simply start computing the date for new keys, letting (much) time take care of it
2. Make a job to compute the expiration date for all keys with a "created" date before the feature was put in place

Note that option 2 would either require that job to maintain some state, or we'd need to keep track in the database whether or not the keys expiration date has been computed yet. But I don't see a clean way to also store this information. We could use some sort of magic date (e.g $MAX_DATE for "never expires", whatever that might be). But that probably just spells trouble down the road?

It would be great to be able to inform users if their uploaded PGP key is expired or about to expire.

The expiration date of a key is expensive to compute and doesn't change unless the key material is updated. Hence, compute it during key upload and store it in the database.

Now that https://git.sr.ht/~bitfehler/vomit-sync/ is a thing, vmt sync should be implemented using that.