Recently,i have tested a peer to peer tool----resilio-sync.It is more simple to share files with people,for example ,input the below string into resilio-sync, you can get resources which someone create
BJOXKVTDB6YWGF5LE5QKSITRDTOYYM3D3
It is a key --not very long string ,smaller than magnet link.
To make syncthing more advanced, set a standard for resources (file or directory to share with) such as resilio-sync do,open the third software for them to download ,syncthing will be more popular!
It is correct that Resilio is more flexible at this point. I can freely share each peer with others.
However, Resilio may also have the disadvantage that the software for receiving data must be installed. I find that a disadvantage, because not everyone can do it. Surely, those who want and need to exchange data regularly via Resilio also install the software, but only to download a few files, for that the motivation is not so high.
I often feel that I only once want to exchange files with someone and cannot count on the software being installed for this. Then I switch to Owncloud or Nextcloud or Synology Drive, in each of these software packages I can generate links that enable handling via a web browser.
What would the resources (by which I guess you mean opaque identifiers that can be used for some functionality) map to in the existing functionality of syncthing?
I am currently trying to find a software to help a large group of people to share files in a decentralized (and secure) way. By being an active member of the Drupal community, I knew that they choosed to use Resilio for this purpose (they share tools to help new contributors to get started). By looking for an alternative to Resilio, I found Syncthing which looks awesome, except for this use case (unless I missed something).
The Resilio use case is really good for my needs: being able to share stuff with strangers by just giving them a key and not having to confirm each person, and to have a read only and a read/write key so I can allow some persons to contribute too.
I’d really love to be able to achieve the same with Syncthing. Do you think it could be possible? Did I miss the way to do it?
So I guess your question is some what orthogonal to the original post, because as far as I am understanding OP was suggesting “resource” to stream line existing processes (hence why I was asking to clarify).
In regards to your question, I don’t think that will ever be possible in syncthing, because of how syncthing is designed.
The device can opt in to be “read only”, but there is no central power that can enforce that, because each node is independant.
Also, this model you are talking about is pretty much just “seeding” the data, effectively content distribution. This is not a usecase syncthing is trying to solve, it’s mostly focusing on continious bidirectional syncing.
There are other tools that solve this, namely torrents etc, so it doesn’t make sense for us to even be in that space.
Also, our trust model is based around devices. Yes, devices are only useful when they share folders, but the first layer of defence/trust is always around the device, so we assume the user added the device because they trust it. In what you are looking for, the trust is mostly around the folder, and not the devices, so if this “public seeding” was ever implemented it would require a large portion of work just to invert the trust model.
I also think it’s good to build on security and to put trust in the center. Nevertheless, I find the attitude mentioned somewhat stuck. If I want to share a peer, I can arrange the sharing in such a way that I can influence data security, e.g .:
If I were to spread it more broadly, I would set up: Read only, time-limited and with a password, which I could change myself, this would be necessary.
Sorry, but it’s not clear to me what you are trying to say
In my opinion, a invert to a trust model is not necessary with such features. I can ensure my data security by using such options as shown.
Not the way it’s implemented now. Now everything is based around devices, not folders. In your screenshot, most stuff revolves around folders, not devices.
Also, the features you show in the screenshot are already inverted, suddenly there is an “owner” of data in a decentralised system.
TL;DR: I would love to have one-click links with an optional password to instantly share a folder with an arbitrary syncthing peer without having to do the ‘both devices confirm they trust each other AND both devices confirm they want to share the folders with the other device’, throwing in optional conditionals for uses remaining, time limits and read-write settings, but it won’t be trivial to do.
And I may or may not have offered a possible solution that is just as much work if not more than inverting the device and folder ID trusts 
, I don’t know so apologies if that is the case.
It’s probably not the best way to go about this, but down the road, if the Syncthing maintainers decided ya’ll do want to offer functionality to share a single folder at a time, with limited uses, time, and/or password settings, all via a single hyperlink, you might be able to accomplish this without requiring the inversion of trust between device IDs and folder IDs. One proposal on how this might be accomplished is below.
Bob wants to share data with Alice. Alice has syncthing installed / is running a theoretical syncthing-in-browser instance, but they haven’t exchanged device IDs / folder IDs
Bob generates a one-time use link on his syncthing peer. This link contains the device ID and folder ID of the data he wants to share, as well as the folder encryption key if the folder is encrypted (in this scenario, untrusted encrypted devices are a completed feature). The link also contains a private & public key, which are for Alice’s peer to generate a temporary device ID that Alice’s peer should present itself as when trying to connect to Bob’s peer.
The device ID would have an issuer and subject as ‘syncthing-temp-link’ vs the standard ‘syncthing’ so a given syncthing peer could easily tell it apart from a standard device id.
How many days the link is active, how many uses remaining, will a password be required, will the local folder be considered to be read/write or send only are options set by Bob and stored to the local database of his peer.
Bob sends Alice the public link via an out-of-band mechanism. Email, Signal, Matrix, IRC, Discord, Passenger Pidgeon, QR code on a business card, etc.
Alice opens the link on her syncthing peer. Her peer adds his device ID and folder ID as a trusted device and active folder. It locates Bob’s peer based on Local / Global discovery and attempts to handshake with the temporary device ID, also including her peer’s real device ID.
The two devices now have a standard device ID / folder ID trust pair. The only change is that Bob’s peer may in the future unshare the folder based on his own local settings.
(If there is a time limit) When the time limit is reached, if Bob has not already hit a button to cancel the time limit, his syncthing peer will unshare the folder to Alice’s peer with a message like ‘expired temporary trust’ and surface the standard ‘Alice wants to share this folder with you, accept?’ message which Alice’s peer would generate via standard behaviors as of today. If Bob clicks yes, then their syncing is resumed via standard methods on a permanent basis.
This solution has the weakness that if Bob shares the folder with both Alice and Jack with temporary and permanent trusts, respectively, AND if Alice & Jack permanently trust each other’s devices AND have this particular folder pair synced, then Alice would be able to continue to read / write that folder via Jack’s peer even though Bob has stopped directly sharing with Alice via his peer. This could be fixed by having Bob not share the real folder ID, but a fake generated one unique to the temporary device ID trust shared with Alice. If the trust were later confirmed to be a permanent trust, the real folder Id would be sent from Bob’s peer to Alice’s peer and updated on both sides.
I think a temporary device ID is not needed - maybe possible once for all short term links. I have understood, that Syncthing model is based on devices and not peers (or folders), which is different in the structure. So maybe a temporary device ID would be a solution for that.
You have to think about, to have one-click links with an optional password to instantly share a folder or some files is what I use with Owncloud or Nextcloud or Synology Drive, to generate a link, as short and fast possibility, to share in one time any content.
So it seems we have different goals. To supply to a lot of people any files and to have one-click links. This is not so easy in the concept of Syncthing, it seems, its a parallel world in the device concept.
I don’t really see the big conceptual issue with introducing devices and folders with a short token: One device just issues that token, the user distributes it to whomever they want, they provide the token to their instance and upon connection there could be a new field in the hello message or an entirely new BEP message that contains the token. Then if the issuer sees the token it adds that device and whatever folders that were chosen when issuing the token. It’s obviously some work though.
Imposing any restrictions on what devices can do or not do is an entirely different, and as far as I can see unrelated pair of shoes. Which has been discussed exhaustively before.
