On the untrusted side when accepting or creating the folder, you need to set its folder type to “receive-encrypted”.
There’s two things to potential improve here: Better error messages and some way to convey the information to the gui that the to-be-added folder should be receive-encrypted.
Ah, I see. Now it is working 
.
Maybe the other folder types should simply be unavailable (i.e. greyed out) when accepting an encrypted folder?
Why does the entire connection between the two devices drop though? Is this expected?
More error messages, this time after trying to manually change the folder type in the advanced configuration. It does not seem to work though. Only by completely removing and re-adding the folder as “Receive Encrypted” I can get the two devices to connect.
2020-11-28 01:08:15 Connection to XXXXX at 192.168.56.1:13620-192.168.56.1:13624/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256 closed: receiving index: illegal base32 data at input byte 1
2020-11-28 01:08:15 Exiting indexSender for rn5bb-vz5is to XXXXX at 192.168.56.1:13620-192.168.56.1:13624/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256: service should not be restarted
There’s no information about whether a new folder is encrypted or not available in the GUI right now. That’s one of the two things to improve potentially (maybe not that easy to do) mentioned above.
Yes, that’s expected: If a device notices a wrongly (un-)encrypted connection it drops that connection.
You are on the RC, right? That’s a bug fixed on main. At this point if you want to test encryption/untrusted, you’ll have to use nightly releases.
I have mentioned this above but it probably got lost in my long posts, but I compiled from main (ab53687) today and have been testing using only that, so I should have all the encryption-related commits.
Hmm, but this seems to persist even after removing the folder from B… Only after removing the folder from A too and recreating it from scratch I seem to be able to get the two devices to connect again.
Yeah missed, then you should be good indeed.
I don’t quite get anymore what exactly you are doing now and which error you see (there have been two: the encryption config one and the base32 one). Could you recap the current situation again please.
Yeah, I am sorry for the confusion.
Let us start again from scratch.
closed: receiving cluster config: folder is configured to be encrypted but not announced thus in the logs.However, this suggests that everything works as expected. I am unsure now how I managed to get the base32 error… as I was using exactly the same Syncthing version then. Now there are no errors.
I will report back once I find the culprit.
I have found a different problem. 9d1ee2f seems to be missing from the encryption GUI. This means that the “Ignore” button for new folders does not work in certain circumstances.
You aren’t suposed to change folder type from/to receive-encrypted. It’s possible that when before you already had scanned items while not being receive-encrypted, that after changing that those items were still around, causing this error.
That’s a noop change, just renameing id to device.
Some things may need to be greyed/disabled on untrusted side : ignores as this makes no sense (real file names being unknown), and some (if not all) styles of versioning (maybe simple trash can could perhaps be kept for restore purpose ?).
Keep zen devs, this is just cosmetic as long as Untrusted isn’t pushed in the wild, allow yourself to postpone.
Yeah this is why we do the testing, there’s a lot of things to tweak before general availability. 
Automatically selecting receive-encrypted folder type when accepting a remote shared that is encrypted for us is pending here: all: Auto-choose recv-enc when accepting encrypted folders by imsodin · Pull Request #7327 · syncthing/syncthing · GitHub
Hi
Does the Untrusted feature still depend on the advanced Feature Flags setting?
Yes.
Should Versioning be allowed in Receive Encrypted folders?
I would personally lean towards having it completely disabled (as it is the case with Ignore Patterns), because restoring files with encrypted names that we don’t know (or shouldn’t know) what they are doesn’t really make much sense.
Is there a potential use case for it?
It’s not obviously impossible for there to be a use case. The versioned files could still be decrypted by a tool. (I don’t off hand remember whether the built in decryptor looks in unexpected directories, but it could.)
This is amazing, I cannot wait for this to be released and to see Syncthing cloud storage providers pop up using this.
Will the web client allow for you to browse your encrypted syncthing folders and be able to manage files in the web client?
2 posts were split to a new topic: Problem adding second trusted device connected to untrusted device
I am closing this topic as it was meant (and used) for early testing. Changes have been made since and a new announcement with a call for testing has been made: Testing Untrusted (Encrypted) Devices
If you have questions/problems, please open a new topic for that.