sa1

Sadly, on the only machine that I would have wanted this on, where I didn't have root access, this has never worked for me.

I should try to recreate the logs and issue for the tailscale folks.

You've hit upon the limits of Signal and other messengers.

The version on app stores is not a closed source version. However it is a binary, and there might be questions on build reproducibility. I do not know the answer to this nor the answer to your MRENCLAVE question.

Virality is because of their philosophy - their first goal is to end mass surveillance, not provide custom software for preventing individual surveillance. The quicker everyone in the world is using E2E, not only is there less mass surveillance, contact discovery leaks zero additional information at that point.

Concerns with SGX are real - but it remains the state-of-the-art - your criticism assumes that the competitors do any better, at this point they do not. They have traditional backends or are as flawed. Signal is doing the hard work on researching solutions at this point, the others are not as close.

> Signal could generate a long enough key locally, and if you want to add another signal user, the client could send it automatically to a contact through SMS. The client on the other side could automatically read the key through SMS and add the contact. Or the user could manually send the key through any mechanism they wanted.

This is what happens when contacts verify each other through QR codes on Signal. But this mechanism does not solve your problem nor are you solving the problem Signal wanted to solve - minimizing data on servers. Even with keys, servers still has to route messages, and with your solution they'll have to maintain a user database.

Here you go: https://signal.org/blog/private-contact-discovery/

> if you give everyone a free $10 everything becomes $10 devalued.

Inflation happens, but the poor benefit much more, as their gains from UBI(as a percentage of their existing income) are more than the loss through inflation.

For rich people, the loss can be more, but this is how inequality is reduced.

They only started sending your contact graph after adopting SGX. Before that the matching used to happen client side through a bloom filter.

They can theoretically rebuild a contact graph by finding everyone you’re talking to, but that’s a small subset of the contact graph created by contact matching.

The code is open source and SGX literally means that the client attests that the code on the server matches what it’s expecting.

Signal might be the most audited stuff out there.

Methane breaks down into CO2 and water in a few years, which is why half life of methane is relevant. My understanding is that for CO2, thinking in terms of half-life is less relevant, the CO2 goes to plants and to the ocean, and if those two sinks are at saturation, then CO2 levels in the atmosphere will keep increasing.

But there's a good article I found now which might shed more light : https://euanmearns.com/the-half-life-of-co2-in-earths-atmosp...

With a phone number, the contact graph can be on the phone. With usernames, the contact graph has to be stored on their servers.

They were forced to store (encrypted) information on servers anyway, since client-side contact matching didn't end up scaling, which is why stuff like this and usernames are now being developed.

Their new security strategy now relies on decryption being done by client-attested code on SGX enclaves, so that the server still doesn't have access to the plain-text contact graph.

All of this took a huge amount of time to come up with, and you can see the progress if you read their blogs or forums.

On the contrary, they started out with phone numbers so that they could avoid storing user data on their servers.

The whole plan to finally have usernames comes down to their use of Intel SGX.

One could choose a better host than Notion, but that's Notion's fault.

It's not just that, it is also a prefix manager, which this is competing with.

Which sounds, like they are meant to be public? If the user has already been identified, public info can’t be expected to be secret anymore.

There are clearly two issues here, only the first one of which has been demonstrated. One is the leak of database names, which is on Apple. The other one is releasing sensitive data on insufficient authorisation(just an user id), which would be on google.

My reading was that a user can be identified by the userid. I'm not sure what other actions just having an userid authorizes, but I would lay that bit on google.

I might be misunderstanding you, but it's a leak of database name, not database contents. You can tell someone visited a website by looking at the name, but your photo from Google is safe.

Apple allows networks to block Private Relay:

"Network settings

Some organizations might be required to audit all network traffic by policy. To comply with such a requirement, these networks can block access to Private Relay. Users will be alerted that they need to either disable Private Relay for the network or choose another network. The fastest and most reliable way to do this is to return a negative answer from the network’s DNS resolver, preventing DNS resolution for the mask.icloud.com and mask-h2.icloud.com hostnames necessary for Private Relay traffic."

https://www.apple.com/privacy/docs/iCloud_Private_Relay_Over...

I haven't tried bazarr, but the feature seems to exist: https://github.com/morpheus65535/bazarr/blob/master/frontend...

Several of these tools over the last couple of years, I use https://github.com/kaegi/alass. Maybe you could manually setup a cron job over your Plex Library.

> A relay can block a user from publishing anything there.

The point is that it won’t be effective since messages are pushed to/pulled from multiple relays.

The post talks more about usability issues rather than any theoretical issues.

There are more fundamental objections to typed holes - but Wingman is kind of the answer to those concerns - with typed holes you're filling in types from the expressions, with Wingman you're doing pretty much the opposite - synthesizing programs from the type.

Now there might be usability issues with Wingman as well, but it represents a different direction - more suitable for type-driven development.

This might be true, but it seems commonly described as the major contributor because it's 40-70% of floating plastic and macroplastics. On the other hand, microplastics sink to the ocean bed. https://hillnotes.ca/2020/01/30/ghost-fishing-gear-a-major-s... I'm not sure which has more environmental impact.

This is only looking at river waste. The major contributor to plastic waste in the ocean is fishing gear. https://www.theguardian.com/environment/2019/nov/06/dumped-f...

Thanks, this might work.

I got my first (Your computer has run out of memory) warnings recently on an Intel Mac (MBP 2015), during normal laptop usage. My pointer settings are already the default. Maybe the laptop is already too old for Monterey.

Maybe he means it came with a sim card.

Thanks, I’ve also thought that something built on rclone or rsync might be more suitable.

I haven’t yet moved to restic, so it might be that find -f is good enough for me.

Thanks.

If a file existed for 3 days and was then deleted, it might make it to 3 daily snapshots, and no weekly, monthly or yearly snapshot.

Even if you’re lucky and the snapshots are not deleted, if you don’t remember when the file existed, currently you need to search through all snapshots. There’s no index or any data structure to speed this search up.

I agree, restoring is fast once you’ve found the file.

Currently I use backblaze, and it does have infinite retention and snapshots, and restoring is fast. But I’m looking to migrate to something that gives me search as well.

I'm not sure, but seems to be an expensive operation on snapshot based architectures - have to search through all snapshots.

Yes, I should have specified that the emphasis is on the use-case of finding and restoring old files.

Yes, a backup tool never deletes by itself, but the standard way of using such tools is that you keep the last n snapshots - this is just delayed sync.

I don't know anything about backup architectures, but is it possible to be more efficient with storage and indexing(for search) if your use-case includes finding files from 5 years ago, but not necessarily recreate the whole filesystem as it was on some date?

I need a backup system in which files are never deleted, even if they are deleted locally. These files should also be easy and efficient to search for; you shouldn't have to go through all previous snapshots, trying to guess which snapshot a file might be in.

Does restic do this?

If it was that easy, https://blog.waleedkhan.name/git-undo/ wouldn't be a thing.