djl0

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.

This is awesome. Monkey Target was my favorite part - I hope that makes it in one day.

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.

FTA: As reported by Heise Online, Signal and Threema will not establish connections allowing for interoperability with WhatsApp.

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.

thank you! very interesting, i'll check those out. do you know of any open source projects?

A little bit off topic, but related: are there any tools to which you can feed a few photos of a room from various angles and it will generate a floorplan or 3d model like this?

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.

Check out a comment i just made to a sibling comment.

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?