I agree that them having users’ phone numbers isn’t ideal. There are other identifiers they could use that would work just as well. However, both the client and server are open source, so you can build, at least the client, yourself. If you can content yourself that it does not leak your ID when sending messages, then you don’t need to trust the server as it does not have the information to build a graph of your contacts. Sealed sender seems to have been announced in 2018, so it’s had time to be tested.

Don’t get me wrong, the fact they require a phone number at all is a huge concern, and the reason I don’t really use it much, but the concern you initially stated was addressed years ago and you can build the client yourself to validate that.

You’re correct that if you use the system the way it used to work they can trivially build that connection, but (and I know this is a big assumption) if it does now work the way they say it does, they do not have the information to do that any more as the client doesn’t actually authenticate to the server to send a message. Yes, with some network tracing they could probably still work out that you’re the same client that did login to read messages, and that’s a certainly a concern. I would prefer to see a messaging app that uses cryptographic keys as the only identifiers, and uses different keys for different contact pairs, but given their general architecture it seems they’ve tried to deal with the issue.

Assuming that you want to use a publicly accessible messaging app, do you have any ideas about how it should be architected? The biggest issue I see is that the client runs on your phone, and unless you’ve compiled it yourself, you can’t know what it’s actually doing.

Strictly you’re having to trust the build of the client rather than the people running the server. If the client doesn’t send/leak the information to the server, the people running the server can’t do anything with it. It’s definitely still a concern, and, if I’m going to use a hosted messaging app, I’d much rather see the client built and published by a different group, and ideally compile it myself. Apart from that I’m not sure there’s any way to satisfy your concerns without building and running the server and client yourself.

‘Sealed sender’ seems to avoid this by not actually requiring the client to authenticate to the server at all, and relying on the recipient to validate that it’s signed by the sender they expect from the encrypted data in the envelope. As I mentioned in another reply, I’m just going on what they’ve published on the system, so either I could be completely wrong, or they could be being misleading, but it does look like they’ve tried to address this issue.

Whilst I absolutely agree it’s correct to be skeptical about it, the ‘sealed sender’ process means they don’t actually know which account sent the message, just which account it should be delivered to. Your client doesn’t even authenticate to send the message.

Now, I’m just going on what they’ve published on the system, so either I could be completely wrong, or they could be being misleading, but it does look like they’ve tried to address the very issue you’ve been pointing out. Obviously it’d be better if they didn’t have your phone number at all, but this does seem to decouple it in a way that means they can’t build a connection graph.

With ‘sealed sender’ your phone number, or any other identifying information, is not included in the metadata on the envelope, only the recipient’s id is visible, and it’s up to the recipient’s client to validate the sender information that is inside the encrypted envelope. It looks like a step in the right direction, though I don’t use signal enough to have looked into auditing it myself.

I know it’s trite to say “calm down Satan”, but, calm down Satan. You’ve captured the spirit of a Fae deal really well.

It’s a non-starter for me because I sync my notes, and sometimes a subset of my notes, to multiple devices and multiple programs. For instance, I might use Obsidian, Vim and tasks.md to access the same repository, with all the documents synced between my desktop and server, and a subset synced to my phone. I also have various scripts to capture data from other sources and write it out as markdown files. Trying to sync all of this to a database that is then further synced around seems overly complicated to say the least, and would basically just be using Trillium as a file store, which I’ve already got.

I’ve also be burnt by various export/import systems either losing information or storing it in a incompatible way.

I think that the point is it’s entirely pointless building something like this into the email system. It should be a separate system that you can choose to use if you want it. Building it in just opens questions about exactly what they’re doing with your data, despite their assurances.

Putting a simple preseed file on a debian install image is probably going to be your best bet. Assuming you can run a VM on your current machine it shouldn’t be too difficult to test it until you’re happy with it.

It’s going to be a balance between your time getting an automated approach to work and the cost/effort of getting a monitor. Getting preseed working can be a bit fiddly, but it does mean you’ve learnt a new skill, getting a monitor sounds like it’ll be a pain, and you might only need it once.

Yes, that’ll work too, it does involve adding the disk to your machine temporarily though, so just be carefully which disk you format to do it. Please don’t ask why I say that, it brings back painful memories…

While I agree with most people here that finding a keyboard and screen would be the easiest option, you do have a couple of other options:

• Use a preseed file A preseed lets the installer run completely automatically, without user intervention. Get it to install a basic system with SSH and take it from there. You’ll want to test the install in a VM, where you can see what’s going on before letting it run on the real server. More information here: https://wiki.debian.org/DebianInstaller/Preseed

• Boot from a live image with SSH Take a look at https://wiki.debian.org/LiveCD in particular ‘Debian Live’. It looks like ssh is included, but you’d want to check the service comes up on boot. You can then SSH to the machine and install to the harddrive that way. Again, test on a VM until you know you have the image working, and know how to run the install, then write it to a USB key and boot the tsrget server from that.

This all assumes the target server has USB or CD at the top of its boot order. If it doesn’t you’ll have to change that first, either with a keyboard and screen, or via a remote management interface sych as IPMI.

It’s the same problem with a drive like this, or any long term archive, you either store the data unencrypted and rely on physical security, or make sure you store the encryption key and algorithm for the same length of time, in which case you still need the physical security to protect that instead. In both cases you need to make sure you preserve a means to read the data back and details of the format its in so you can actually use it later.

Paper is actually a pretty good way of storing a moderate amount of data long term. Stored correctly it’s unlikely to physically degrade, the data is unlikely to suffer bitrot and it can be read back by anything that can make an image in the visible spectrum. That means you can read it, or take a photo and use OCR to convert it into whatever format is current when the data is needed.

I’m using syncthing, but I think I recall the sort of issue you mention. Android locks down cross-app access quite hard, but if you move the files to your SD card (or tge emulated one if you don’t have one) it acts as shared storage and your sync program and obsidian can both read and write to it. On my device, the path is /storage/emulated/0/Documents/<whatever>

If you don’t need external calling you don’t need a trunk, it’s just for connecting to the outside world. I found [[https://www.asterisk.org/|Asterisk]] was a good place to start. The config is rather involved though, so there are various front ends for it.

You can sync Obsidian yourself too, it’s just a bunch of files, so anything that’ll handle them works.

You can, but I found it a bit laggy. It basically wraps your tcp stream over https, so I think the extra overhead was what was slowing it down.

Ah, ok. You’ll want to specify two allowedip ranges on the clients, 192.168.178.0/24 for your network, and 10.0.0.0/24 for the other clients. Then your going to need to add a couple of routes:

• On the phone, a route to 192.168.178.0/24 via the wireguard address of your home server
• On your home network router, a route to 10.0.0.0/24 via the local address of the machine that is connected to the wireguard vpn. (Unless it’s your router/gateway that is connected)

You’ll also need to ensure IP forwarding is enabled on both the VPS and your home machine.

Sort of. If you’re using wg-quick then it serves two purposes, one, as you say, is to indicate what is routed over the link, and the second (and only if you’re setting up the connection directly) is to limit what incoming packets are accepted.

It definitely can be a bit confusing as most people are using the wg-quick script to manage their connections and so the terminology isn’t obvious, but it makes more sense if you’re configuring the connection directly with wg.