Pulse: open, trustworthy, decentralised sync and cloud service(ind.ie)
ind.ie
Pulse: open, trustworthy, decentralised sync and cloud service
https://ind.ie/pulse/
7 comments
The first sentence on the page:
>Syncthing is becoming Ind.ie Pulse
would indicate it's a rebranding, but I see no evidence on the Syncthing side of things that this is the case
>Syncthing is becoming Ind.ie Pulse
would indicate it's a rebranding, but I see no evidence on the Syncthing side of things that this is the case
The evidence is here: https://discourse.syncthing.net/t/introducing-pulse-and-ind-...
I'm also using SyncThing to sync some web servers, it sort of works well, though I wish it handled conflicts and symlinks better.
In my case git hooks would not have worked as each web server generates content that needs to be available on all of them afterwards.
I hope they're going to do well and get it to work smoother.
In my case git hooks would not have worked as each web server generates content that needs to be available on all of them afterwards.
I hope they're going to do well and get it to work smoother.
The recently added "introducer" feature allows you to establish trust relationships between all nodes which have access to a common repository on a node automatically.
Tag your "central" server as an introducer on all of the other node configs, and they will all add each other (assuming they have any repositories in common). This really aids in this use case.
Tag your "central" server as an introducer on all of the other node configs, and they will all add each other (assuming they have any repositories in common). This really aids in this use case.
I wonder if this is why syncthing just switched to the GPL: https://github.com/syncthing/syncthing/commit/9edce23e76c7fb...
Bummer.
Bummer.
A description of the relationship between Pulse and Syncthing is here: https://discourse.syncthing.net/t/introducing-pulse-and-ind-...
It appears to be a valid rebranding of the project from the developers, who are interested in extending their desire somehow to a privacy-centered phone OS? Seems like quite a big pivot.
It appears to be a valid rebranding of the project from the developers, who are interested in extending their desire somehow to a privacy-centered phone OS? Seems like quite a big pivot.
The phone idea already existed before. This is an alignment of previously separate projects, I think, not a pivot of one project.
According to their "Team" page [1], ind.ie has three designers, one person for operations and a single developer.
With that team, they want to create free versions of Dropbox (Indie Pulse), Android/iOS (Indie Phone), Facebook (Heartbeat)?
Love the idea and intentions, so I hope they get good support on their open-source projects.
[1] https://ind.ie/team/
With that team, they want to create free versions of Dropbox (Indie Pulse), Android/iOS (Indie Phone), Facebook (Heartbeat)?
Love the idea and intentions, so I hope they get good support on their open-source projects.
[1] https://ind.ie/team/
I keep hearing that Syncthing (Pulse) is just like BTSync, except you set it up manually, and that the developers don't have any plans to add peer discovery.
But peer discovery is the whole point of BTSync. Sure, Syncthing/Pulse is an improvement over rsync, but only an incremental one. BTSync, with its peer discovery, is a radical improvement.
Even having a roadmap for peer discovery would make me a lot more interested in it. As it is, no thanks, I have better things to do than maintain N^2 configuration problems.
But peer discovery is the whole point of BTSync. Sure, Syncthing/Pulse is an improvement over rsync, but only an incremental one. BTSync, with its peer discovery, is a radical improvement.
Even having a roadmap for peer discovery would make me a lot more interested in it. As it is, no thanks, I have better things to do than maintain N^2 configuration problems.
There is a global syncthing discovery service. Nodes can locate each other by ID using that service. The code for that server is open source and you can run your own on your own network. Individual nodes on the same subnet can discover each other without the discover service.
You do need to know the node ID and repository ID, and the nodes both need to establish that relationship. But the mutual acceptance of the node ID is how trust is established so I don't see how that could be made optional. They could allow for UI improvements where the user is prompted to add a repository that has been published from another node rather than requiring that to be manually added, but that's just a ui change.
I haven't used btsync so I'm unclear on what specifically is missing on syncthing in this respect. It seems to be pretty good with respect to discovery.
You do need to know the node ID and repository ID, and the nodes both need to establish that relationship. But the mutual acceptance of the node ID is how trust is established so I don't see how that could be made optional. They could allow for UI improvements where the user is prompted to add a repository that has been published from another node rather than requiring that to be manually added, but that's just a ui change.
I haven't used btsync so I'm unclear on what specifically is missing on syncthing in this respect. It seems to be pretty good with respect to discovery.
BTSync is a radical improvement in the network protocols but I still can't get the btsync web ui to change my password. You could say that their priorities are in the right place for an open source project, which they are not.
Don't get me wrong, I love the concept and most of the implementation of btsync. But they are holding themselves back, leaving an opportunity for projects like Pulse.
That said, Pulse is dead in the water without peer-discovery. How do I connect to a peer with Pulse if there is no central server?
I suspect that you have specified a password in your BitTorrent Sync configuration file. Settings set in the configuration file will override settings set through the WebUI (after restart). Consider specifying your password either in the configuration file or using the WebUI, but not both.
I'm a bit worried that, as far as I see, the Syncthing protocol doesn't really allow having servers/peers that don't see plain-text. (Since I think it mostly just uses TLS to keep things secret from eavesdroppers.) I've always been looking for an open source Dropbox-like that allows having storage that only sees ciphertext (despite the fact that it would require a little key management from the user, which I think is a usability challenge, but one that can be overcome).
BitTorrent Sync has functionality for generating "encrypted secrets" using the developer API. It is possible to deliver a secret key to a peer which only allows for that peer to access encrypted versions of the folder content.
did you take a look at sparkleshare,
it's kind of a dropboxreplacement based on git.
Last time i checkt it was possible to enable ciphertext storage ( https://github.com/hbons/SparkleShare/wiki/Client-Side-Encry... ) .
Look at boxcryptor (works with dropbox)
That's such a non-descript name, I don't think this is a good move. Syncthing is great, it's a thing to sync things. Dropbox, the box where you drop files into. BTSync uses BT to sync things. Pulse? Uhm, maybe it's something about heartbeats or social media analysis?
Recently set up Syncthing on Raspberry Pi, N900 and Win7 laptop for the 'perfect' synchronised notes (mainly notes, anyway) system. Can also report low enough resource usage to be useful on these systems. The phone battery life is not significantly affected and the Pi continues to play media, run Tmux and perform backups without hesitation.
Memory use is consistently under 15 MB and CPU use in the low single % figures. I am only syncing my notes, for the most part, but it fits the bill perfectly.
Excited to see where the project goes from here, having just read about the Indie team's phone project in Linux Voice recently.
Memory use is consistently under 15 MB and CPU use in the low single % figures. I am only syncing my notes, for the most part, but it fits the bill perfectly.
Excited to see where the project goes from here, having just read about the Indie team's phone project in Linux Voice recently.
I just implemented Syncthing on a cluster of front-end web servers. I know best practice would be using hooks to make all my web servers update from a Git repository, but I prefer to do dev on one server and then just update one production server when I go live. Syncthing simply replicates the right directories to the rest of the front-end servers.
I have 8 static asset web servers that run on low-end VPS's with just 256 megs of memory. Syncthing only consumes about 15 megs of that precious memory, leaving plenty for Nginx.
Syncthing is competing with BTSync. BTSync has the disadvantage of being a closed-source product, but it's far easier to setup and configure. Syncthing will take a bit of configuration to get everything just right. It also comes as a plain binary without a native way to make it a system daemon. You have to come up with your own init.d, move config files to a shared directory, set the right permissions on that config file directory, etc.
BTSync is also a lot easier when it comes to adding shared folders. With their system, you share a folder on one computer and receive a key and a secret. On other computers, you simply pick an empty folder, enter the key and secret, and then everything synchronizes.
With SyncThing, you have to configure the relationship on all sides of the connection. When you start setting up a big mesh of dozens of machines, this gets very very tedious and you find yourself just picking one machine to be the "master" and pointing each machine to that one master. This has the downside of not being able to source pieces of the replication from all of the various servers.