Yeah, I just searched a bit and found this https://stackoverflow.com/questions/28348678/what-exactly-is-the-info-hash-in-a-torrent-file

The torrent file contains the hashes of each piece and the hash of the information about the files with the hashes of the pieces, so they have complete validation of the content and amount of files being received.
I wonder if the clients only validate when receiving or also when sending the data, this way maybe the seeding can be stopped if the file has been corrupted instead of relaying on the tracker or other clients to distrust someone that made a mistake like the OP of that post.

How torrents validate the files being served?

Recently I read a post where OP said they were transcoding torrents in place and still seeding them, so their question was if this was possible since the files were actually not the same anymore.
A comment said yes, the torrent was being seeded with the new files and they were “poisoning” the torrent.

So, how this can be prevented if torrents were implemented as a CDN?
An in general, how is this possible? I thought torrents could only use the original files, maybe with a hash, and prevent any other data being sent.

I’m just annoyed by the regions issues, you’ll get pretty biased results depending in what region you select.
If you try to search for something specific to a region with other selected you’ll find sometime empty results, which shows you won’t get relevant results about a search if you don’t properly select the region.

Probably this is more obvious with non technical searches, for example my default region is canada-en and if I try “instituto nacional electoral” I only get a wiki page, an international site and some other random sites with no news, only when I change the region I get the official page ine.mx and news. For me this means kagi hides results from other regions instead of just boosting the selected region’s ones.

It’s regarding appropriate handling of user information.
I’m not sure it includes PII. Basically it’s a ticketing system.
The pointers I got are: the software is secure and reliable to store the data and be able to be queried to understand the updates the data had.

I’m just downloading moonlighter again xP
It’s also included in Netflix, but the reviews say it crashes and data gets corrupted.

Not OP, but I’m thinking about the example in vs code: https://code.visualstudio.com/docs/editor/userdefinedsnippets
Some boilerplate code for libraries and frameworks I constantly use.
I’d be more interested in syncing the VS code snippets as they are automatically available in a file for each language and have the autocomplete stops.

I want instances that block as few other users as possible so I can decide for myself what content I see.

Then you want to selfhost, otherwise you’ll always be at the will of someone else to decide which instances they want to federate with.

Even then, you’ll still want to have in mind instances known for spam, bots, or shady content have been blocked.

Thanks for all the information and advises!

So in theory basic auth is enough when sent through HTTPS, right?
If this is the case then the user would need to handle their password and my API can keep storing just the hash.

In another comment JWT was suggested, maybe this could also be a solution?
I’m thinking the user can worry about generating and signing the token and we could only be storing the public key , which requires less strictness when handling it, this way we can validate the token has been signed by who we expect and the user will worry about the private key.

Oh I’ve only used JWTs with OIDC so I didn’t thought about using them directly.
It could be a good solution since the user can generate them on their own and we can validate them with the correct information (secret or public key).

About the issue of long lived or not expiring JWT, maybe a custom restriction of valid tokens with lifespans of more than X amount of minutes are rejected?
Yeah, the token could be a valid one but we could say the payload is invalid for our API.

Completely agree with you, I made that comment, but most people agreed with the client '-.-

I agree, the token has a lifespan of some hours so it could be generated after that amount of time, which for a ~400ms call is not that much, but I was overruled .-.

The only thing I control is the API, the client’s implementation is outside of my control (although I know is a backend service).

Someone want’s me to implement a way to access a resource without having to make the extra HTTP calls required by OAuth, WSSE is a possibility since I saw it had some standards to send the credentials in a secure way.
I have been reading about WSSE for less than a week '^-^

Yeah, the idea would be the tokens used to generate the digest WSSE requires will live in our secure environment, and that’s the question: how is a secure environment created to store tokens/API keys of users which will be used to authenticate them into my API?
I haven’t implemented this kind of stuff so I don’t know what are the best practices to store this kind of sensitive data.
So, I’d need to research password vaults to store my user’s secrets so I can use them to authenticate them?

I went into WSSE since sending a client id + secret seems just rewording of basic authentication and well, sending the credentials in plain text seems more insecure than sending a hash.

Well, an “extra HTTP call” is any call besides the one required for the client to access my API, in this case is an extra call to generate an access token.
Why does it matter? In words of the client: “making a call to generate a token is slow”

Based on the title you’re right, I asked about how to do X when probably I need to do Y, but the first and last paragraphs mention what’s my requirement: a for of authentication which doesn’t require to make an extra HTTP call to generate a token.

And what I mean by this is OAuth specifies the client needs to request an access token and an optional refresh token to the authorization server, afterwards the access token can be sent to the resource server (in this case my API), if the token expires the client can make another request to the authorization server with the refresh token.
Each call to the authorization server is that “extra http call” I mentioned.

Currently the only solution I found which seemed somewhat secure was WSSE, but again, I’ve only worked with OAuth2 and hashing passwords (or even better, using a dedicated service like keycloak), so I’m not sure what’s the best option to store the data it requires or if there’s a better solution.

I don’t know how to be more clear, is there a way to authenticate a client to the resource server (my API) without making the client call endpoints to generate the tokens? Is there a way for the client to generate their own tokens and for me to validate them?

You’re right, thank you for pointing me into the right direction!

I found this explanation https://stackoverflow.com/questions/11697943/when-should-one-use-connect-and-get-http-methods-at-http-proxy-server
And this issue with axios which includes the current workaround https://github.com/axios/axios/issues/4531

and unblocks SvelteKit

Hahaha, nice, I was just going crazy on why my setup was no longer connecting to my dev svelte project :D
The websocket was just hanging the connections and I even went as to try it with node.

Oh, yeah, I had forgotten about this kind of attack.

Do you think this is a concern if the calls are only meant to be done in an internal network?

Yeah, mentioning password it was just an analogy, the user has their credentials independent of this implementation, so no need to reset their password for any flow here. It’d be client id+secret.

You got me thinking in something more, are API keys stored in plain text in DB? Otherwise I don’t see a way to quickly know it’s valid, I’d have to validate it against all the hashes in the DB.
With client id it’d be easy to just validate the secret against a single hash for that user.

I don’t fully understand what use case you’re thinking about.
An API key which expires is very hard to work with, imagine deploying an app with that kind of key, or a service/bot which uses that key.

Maybe you’re thinking about access tokens, which need to be regenerated every so often and can be generated with a refresh token.