Is it the word “lawyer” or spending some small amount of money?

Lawyers are bound by law and an ethical code to conduct business in a particular way. They also tend to have support infrastructure and continuity plans that private individuals do not.

If making sure something actually happens is important to you, this is the best option.

Your question, as best as I could tell, is that you want DNS traffic to exit through your VPS node, rather than your client machine.

I posited one reason this could be happening, and additionally, a similar setup that provably routes traffic through the VPN based on the method I described.

Nobody in here is obligated to help you, I gave you a couple threads to pull on to resolve your question, so maybe consider accepting it graciously, rather than being obstinate.

Of course, you have to trust that third party, which may/may not be prudent.

My running joke, after four different friends told me they were using ChatGPT to help them with it, is that the language is so hard to learn that we invented an entirely new class of AI to help.

It’s a joke, of course, but it does have some “surprising” syntax, since some stuff is whitespace sensitive, and there are subtle differences between () and [] and [[ ]], for example. All of that’s due to the long history of shell behavior, so I don’t necessarily blame bash.

Cool. I should check it out. I tend to assume that when Apple (or Google) rolled this out that it’s not broken in any obvious way that I would recognize right away.

But like contactless payments, which I’ve advocated my friends and family switch to, I should read up on why it’s more secure.

I take what they're saying as "don't just give up/refuse to answer" - it's fine to say "I don't know, but I have a guess on how I'd start/find out" and try to work through that. In a real working environment, this is more how it'd work, and if someone truly didn't know where to start, usually the co-worker would try to help, which is not always how interviews go.

I’m pretty sure you can delete releases. Probably worth a do-over

There is no incentive for adding the friction of gas or PoW for these types of systems.

The parties involved can have a shared log and private keys for signing entries. Party A provides a thing and Party B signs an entry that says they were provided with the thing. Party A can wait for that signed entry before releasing the goods, etc. The problem with block chain to track physical stuff is that that handoffs are not instantaneous, so there’s always lag between the real state of the world and what the log says. In practice, this may be a few seconds, and a human might wait for confirmation before physically granting access to a recipient.

To put it another way, the party that is signing is not incentivized to forge that they have received an object from someone else, as that is effectively the fulfillment of the obligation. They’re only going to sign an entry if they get the object.

Sorry, I didn't mean to reference the detail member, I meant "extension members" as defined in the RFC.

In the RFC, they are outlined as top-level elements. In the version I proposed, these are bundled up inside of an optional context member. This can be useful in making the serialization and deserialization process a little bit easier to implement in languages that support generics without the need to subclass for the common elements. The RFC specifically defines "extension members" as optional. The key difference is that in what I was describing, they'd be bundled into one object, rather than being siblings of the top-level response.

It also side-steps any future top-level reserved keyword collisions by keeping "user-defined" members a separate box.

You seem to be laboring under the notion that this spec produces something that can be entirely negotiated by generic clients, but I don't see that at all. Even for "trivial" examples (multiple validation errors, or rate-limiting thottling), clients would need to implement specialized handlers, which is only vaguely touched upon by the need to have a "problem registry".

And, like it or not, considering how easy or messy it is for a downstream client to consume a result is actually an important part of API design. I don't see how considering the browser, javascript, and the Fetch API behavior aren't relevent considerations when we're talking about extending HTTP with JSON responses.

Did you author this RFC? I don't exactly understand why you seem to be taking the criticism personally.

Thanks, and you are basically correct on both counts:

• I supported an API that had a Batch endpoint that could be "partial success" -- and that was a mess.
• I have been experimenting with something where you have standardized elements because the Fetch API doesn't throw on 4XX/5XX, so having one if check, rather than two, makes sense.

At this point, it's an experiment.

Context is whatever makes sense to provide to a consumer to help them debug it or respond to it - the same basic idea as in the rfc under details. IMO, it can't easily be generalized. Some APIs may have context to provide, others may not. These could be validation errors in a structured format, or backoff timings in the case of a 429.

Success is something that you can sniff for after deserializing, as IIRC Fetch API will not throw except for a network errors, even in the event of a 4XX or 5XX.

Consider something like:if(!obj.error_code){} vs if(obj.success){ }. Certainly, you could consolidate the error_code and success member, but with the sloppy truthiness of testing in Javascript, including something like that as a standard part of all responses may make sense.

I use miniflux, and you can configure it to modify feed items. As far as I know it does not purge anything by default.

Really, pulling an RSS feed and parsing it, storing stuff is probably 50 lines of bash, and less in a general purpose scripting language.