calmh
(Jakob Borg)
January 31, 2016, 6:45pm
1
I was thinking we could post an application to GSoC this year.
Google Summer of Code (GSoC) is a global program that matches students up with open source, free software and technology-related organizations to write code and get paid to do it! The organizations provide mentors who act as guides through the entire process, from learning about the community to contributing code. The idea is to get students involved in and familiar with the open source community and help them to put their summer break to good use.
(Home | Google Summer of Code )
For this, there needs to be a list of ideas that students can choose from. I have some, below. Add yours as well, I’ll aggregate and curate.
opened 04:47PM - 09 Feb 14 UTC
closed 01:45PM - 10 Mar 23 UTC
enhancement
I.e. ones that we never accept updates from, but who can otherwise participate i… n the exchange as usual. Needs #63 to work securely.
opened 03:07PM - 04 Apr 14 UTC
closed 08:13AM - 13 Apr 21 UTC
enhancement
So I have had a look at BitTorrent sync, syncthing and alternatives and what I a… lways wondered about was the possibility to not only sync between resources I own and trust, but also external resources/servers which I do NOT trust with my data, up to a certain extent.
One way to do this is using ecryptfs or encfs, but this has many obvious downsides: it is not an interoperable solution (only works on Linux), the files are actually stored in encrypted form on the disk (even if the resource is trusted and this is not necessary, for instance because of the file system being encrypted already), etc.
What I propose is somehow configuring nodes which are only sent the files in an encrypted format, with all file contents (and potentially file/directory names as well; or even permissions) being encrypted. This way, if I want to store my private files on a fast server in a datacenter to access them from anywhere, I could do this with syncthing without essentially giving up ownership of those files. I could also prevent that particular sync node from being allowed/able to make any changes to the files without me noticing.
I realize that this requires a LOT of additional effort, but it would be a killer feature that seems to not be available in any other "private cloud" solution so far. What are your thoughts on this feature?
EDIT: BitTorrent sync mentions a feature like this in their API docs: "Encryption secret
API users can generate folder secrets with encrypted peer support. Encryption secrets are read-only. They make Sync data encrypted on the receiver’s side. Recipients can sync files, but they can’t see file content, and they can’t modify the files. Encryption secrets come in handy if you need to sync to an untrusted location." (from http://www.bittorrent.com/intl/de/sync/developers/api)
opened 11:23AM - 08 Oct 14 UTC
closed 08:01PM - 08 Mar 17 UTC
enhancement
This is a long-shot, over-engineering and is not required, but a interesting top… ic nonetheless which could be a unique selling point to Syncthing.
Some interesting ideas can be found [here](http://stackoverflow.com/questions/107668/what-do-you-use-when-you-need-reliable-udp)
I seems that the easiest one to adopt would be [UDT](http://udt.sourceforge.net/) with bindings already available for most languages.
opened 04:33PM - 02 Jan 16 UTC
closed 02:11PM - 04 Nov 17 UTC
enhancement
frozen-due-to-age
It could in some cases be neat to store data somewhere else than on local disk. … Primarily I'm thinking of things like Amazon S3 and Joyent Manta - essentially glorified object stores with a REST interface. The use case would be to keep an off site mirror of a folder, perhaps directly used for web serving or something.
There is a complexity in that if we are asked for a block, or need to update a block in a file, we usually would need to download or upload the entire file, not just the block in question. For serving data this could be backed by a local disk cache, so we fetch the file on first reference and keep it around for a while. For updates it would probably mean the same, with upload happening when sync of a file has completed.
An alternate model is to not store _files_ in S3 but the actual block objects, named by hash, plus something like a serialized copy of the index. This makes updates and requests more efficient, at the price of not having the data immediately available in actual file format. As an aside, encryption would be much simpler to implement in this case. The keys and so on would live on the box that runs Syncthing, and the actual remote storage would just store encrypted blocks and have no knowledge of the keys.
opened 01:48AM - 08 May 15 UTC
closed 09:51AM - 28 Jun 17 UTC
enhancement
Let's talk about my case:
I've 2 servers and 2 computers with syncthing on.
Serv… ers sync between them www with symlinks that needs to stay as it (like in current state)
Computer 1 sync with everyone else a folder with symlinks pointing to differents area of my computer (appdata.purple, appdata\thunderbird, userprofile\documents, etc.).
These symlinks need to be treated as if they were real folders. Instead, syncthing currently treat every symlink as a simple file, hence does not backup my data.
Is there a way to add an option in folder sync parameters to treat symlinks inside as links or as folder?
Thanks.
opened 01:09PM - 22 Sep 15 UTC
enhancement
Hi,
I would love to work towards replacing Dropbox with Syncthing, only that tr… ying to walk people through "add my device, then I add you back (yes you have to copy that code and send it to me!), then you can add the folder (no, it has to be spelled exactly like this! Dont change anything else! No you are not a master!) and as soon as I added you to the folder, everything works!" mostly results in "Can't we just use Dropbox?"
Here's how "Invitations" would come in, in three stages:
**Stage One**: Syncthing is able to open a special kind of XML files (and associated with those files on the operating system). These XML files contain two sections:
- One section containing informations about devices to pair with (Key/ID, name, discovery server used?)
- One section containing informations about folders to be added (Folder ID, devices that this folder exists on (referencing the pre vious section))
If Syncthing is told to open one of these files, a dialogue should pop up (I know, that's hard to do with a web interface) asking the user for each folder in the XML file what local folder to use (cautioning that all contents of that folder will be shared with the devices listed in the device-section). _All other settings should be hidden_, perhaps collapsed and expandable via "Extended Settings" or whatever. After that, the own ID should be displayed with a message "please send this ID to whomever you got that file from".
This would make the use case of "me adding someone to my shared folder" a two-step process on the receiving side (open file, confirm, send displayed ID).
**Stage Two**: On top of that, every device entry in the XML file can optionally contain a one-time (secret) key used for pairing: The client opening that file (call it device A) signs his own public key (aka "A's ID") with that one-time key and sends it to the device that the one-time key is associated with (device B). B then adds A and shares preconfigured folders with it (preferably those listed in the XML file) with A, without requiring any user intervention. This would make invitation a one-step process. On the other hand, anyone able to intercept the XML file will be able to gain access to the share. But, realistically the XML file as well as the returning "My devices ID is XYZ" will both be sent via the same medium, so someone able to intercept the XML file is probably also able to tamper with the device ID sent back. However, including this "authorization token" should be strictly optional. If no such token is present, the ID has to be added manually on device B.
**Stage Three**: Build a nice UI for creating these XML files in Syncthing. This would be more or less necessary after Stage Two anyway, since the authorization tokens (and what folders they authorize access to) must be somehow stored in the Syncthing instance issuing these tokens.
If something like this was implemented, I think handling sharing files with Syncthing would be just as easy as with Dropbox (or whatever). I do realize this is a rather huge implementation request (and I can't write a word of Go, or I would possibly even help ;)), but I'd like to discuss this.
opened 06:59AM - 22 Nov 15 UTC
enhancement
In some situations it may be desirable to for the device TLS key to be stored on… disk in encrypted format. This then requires inputing a key at each startup to unlock the key. The code is fairly simple, we have the technology in the Go stdlib. User experience wise, this could be implemented in two phases.
## Phase 1, command line
```
$ syncthing -encrypt
[info] Will encrypt on disk key material.
Password: <user enters password, no echo>
Verify password: <user enters same password, no echo>
<syncthing encrypts and resaves key.pem>
<syncthing exits>
```
```
$ syncthing
[info] Key is encrypted, enter password to unlock.
Password: <user enters password, no echo>
[info] Key unlocked, continuing.
<normal startup proceeds>
```
## Phase 2, actual UI
We would need
- a rest method `POST /system/key/encrypt`, only supported over HTTPS, that encrypts the key with a password
- a GUI to get a password and perform the POST
- a special mode when starting up where we launch the GUI but nothing else
- GUI support for this mode, where the GUI only asks for the password to unlock the key
- a rest method `POST /system/key/unlock` that unlocks the key and lets startup proceed
opened 09:19AM - 28 Jan 16 UTC
closed 11:26PM - 26 Nov 17 UTC
enhancement
frozen-due-to-age
See #9 and https://forum.syncthing.net/t/syncthing-inotify-merge/6653
4 Likes
rumpelsepp
(Stefan Tatschner)
January 31, 2016, 6:49pm
2
I would be happy to see these guys emerge:
I have come up with the idea of device priorities and I would like to propose this here. My common Syncthing setups suffer from a very annoying problem. The setup is as follows:
One/two boxes are a server with reasonable bandwith.
Other nodes are laptops/desktops with high downstream and a very low upstream bandwidth.
When a lot of nodes are online and I drop a large file into my Syncthing folder, Syncthing uploads the blocks to each node at the same time. This is very annoying when you have …
1 Like
rumpelsepp
(Stefan Tatschner)
January 31, 2016, 7:19pm
3
@calmh : What about your delta indexes stuff? Is that one close to be finished, or is that a candidate for GSoC 2016 as well?
1 Like
calmh
(Jakob Borg)
January 31, 2016, 7:42pm
4
Something in between. I’ll have another look at that one once I’ve completed the stuff I’m working on now. It needed a couple of final adjustments that I thought were annoying and onerous at the time but things may have cleared up since.
calmh:
Consider using reliable UDP for block transfers
Leave this for me.
I plan to work on this (essentially adding that utp lib we found) once the temp indexes get merged.
2 Likes
Nutomic
(Felix Ableitner)
February 1, 2016, 12:19pm
7
Golang support for Android Storage Access Framework . Might be out of scope, but would be really helpful for Android.
Also, a Syncthing implementation in the JVM.
3 Likes
sm86
(Shashank Motepalli)
February 7, 2016, 5:41am
8
I am Shashank, student from India. I would like to work with Syncthing for GSOC 2016. Please help me get started.
3 Likes
lkwg82
(Lars K.W. Gohlke)
April 1, 2016, 10:41pm
10
Did I get it right, when I say we missed application for the Google Summer of Code 2016?
calmh
(Jakob Borg)
April 2, 2016, 6:16am
11
Yep. I didn’t have the time or energy to deal with it. Sorry.