HN user

djl0

16 karma
Posts1
Comments15
View on HN

do you have any provider recommendations? I've experimented with this on runpod serverless, but I've been meaning to dig deeper before I feel comfortable with personal data.

I saw a service named Phala, which claims to be actually no-knowledge to server side (I think). It was significantly more expensive, but interesting to see it's out there. My thought was escaping the data-collection-hungry consumer models was a big win.

In terms of the actual topic, I would be shocked if Williams approved of spiking the CECOT 60 mins story, if it is in fact politically motivated as many suspect. And I'm not particularly a "fan" of Williams or anything, though I've heard him on a couple of podcasts.

But you're also making this point about all signatories being hypocrites because you seemingly have a big bone to pick with the amount of blame Thomas Chatterton Williams portions to each side.

I think you're really off base. A quick search about what Williams has said about censorship on the right seems to undermine your one non-weiss example [1]. There were more than a hundred signatories from across a fairly wide political spectrum (and the letter itself was anti-Trump). The handful of signatories that I follow have squarely denounced right wing censoriousness - I'm open to hearing that I'm seeing a non-representative sample, but you didn't provide any useful info on that front.

[1] https://www.theatlantic.com/ideas/archive/2025/02/woke-right...

Correct me if I'm wrong, but the way you use "traditional", basically means "written in C", right? I certainly can sympathize with your point about the frustration of compatibility issues in your narrow usecase (though I don't agree that it should affect what options we have), but connecting to the original commenter's point, it's really common for libraries in python to be wrappers for things written in other languages.

1. At initial rollout, I don't imagine end users would be in charge of their own keys. State-managed keys un-does some of the benefit of being on the blockchain at all, however it sets up a modularity for the future where people could choose to take their own keys.

2. The blockchain can still have similar checks for fraud. IE I'd still imagine the DMV-approved key needs to sign-off on whatever transactions normally pass through the dmv, and perhaps with in-person paperwork. Some crypto maximalists imagine a world where cars and houses are on the blockchain and there are smart-keys or something that prove ownership. That doesn't seem realistic or desirable, however smartcontracts that mimic our current checks could be a big improvement over our current state administration.

In this case, I'm saying that the state can leverage the blockchain for infrastructure and DB access/permission/security. I haven't worked in this specific space, but having a state-affiliated key signing off on a blob of data and store that on the blockchain (and using a standardized open-source front-end for state-side or citizen-side view and editing) has potential to be a much more elegant and robust solution than every state agency around the world creating it's own front and back-end.

I agree that in this case it's not about abstracting trust from centralized authority.

I've never heard of this project, so I can't speak to its implementation, however blockchain to handle DB + access api for relatively slow db operations I think is one of the rare great current blockchain use-cases. If done well it has the potential to be a piece of open-sourced infrastructure. And once it's done once well, it could be replicated to every dmv-like entity (IE almost every permit or sign-off based process) in the world. And the comparison to a state-run database, I think many of us would agree that is an area where there is plenty of room for improvement.

But this is the first I'm hearing of this project, so I'm not advocating for it specifically.

I'm interested to see this podping service, however given the whole model of RSS is that the end-user is requesting feed updates (I would guess daily on average, but maybe hourly?), I have a hard time thinking this was a problem for podcast providers. I have no knowledge of the implementation at scale, but given the feed is static for the most part, wouldn't podcast hosting providers want their users constantly checking in?

If Iran is blocking Signal but not other apps, namely Whatsapp, does this mean Iran has access to Whatsapp data?

I fully expect the US govt to have access to fb/whatsapp data (at least the metadata), but it's a bit surprising to me that Iran would too.