Toc is a project I've been working on for more than a year now. I'd love to hear what you guys think about it. =)
Toc is a proof-of-concept distributed messaging app designed from the ground up to support user data synchronization for use across multiple devices. It uses Telehash for its messaging stack, and is built on top of an Om-inspired architecture oriented around a central app state tree that gets encrypted using a custom encryption layer for persistence locally, and then synchronized seamlessly between devices using remoteStorage.
Originally, Toc started as our group's fourth year Computer Engineering design project at the University of Waterloo. After we graduated in May, I wanted to polish it up a bit before releasing, but evidently went a bit overboard and ended up working on it for another six months (albeit with a healthy dose of procrastination sprinkled throughout that period).
Toc is only a proof-of-concept, and has a list of awful issues that makes it rather unsuitable for long term general use. However, I'm hoping that by releasing Toc, we can bring more attention to the awesome technologies for building great decentralized applications that Toc uses, and inspire more developers to take another serious look at building distributed apps, as I hope we have demonstrated with Toc that a decentralized app can in fact have great UX if you design your apps with UX in mind from the start.
With that said, I am now officially looking for work. If you have any openings for a ClojureScript frontend project, or a React project that makes heavy use of functional techniques and immutable data, I'd love to hear about it. You can reach me through the email on my GitHub profile[1], HN profile[2] or through my Toc account[3]. ;) (disclaimer: that last option might not be completely reliable)
Not sure about whether it's the most advanced... Toc's feature set is pretty sparse (text chat only) considering what Telehash is capable of. We do hope it's the most user friendly one though. =)
The seed server I'm running probably can't handle all of them doing bootstrapping at the same time, but once they're bootstrapped and have their own lookup tables stored locally, theoretically it should scale much better than a traditional centralized app since individual messages and status updates won't need to be coordinated through any single server.
Of course, the Telehash version I'm using is very old and unsupported, so there's no guarantee that its integrated DHT can handle any significant scale.
All messages in the app are sent through channels that support an arbitrary number of recipients. That arbitrary number just happens to be always set to 1 at the moment.
A naive group chat implementation (i.e. an inefficient one where every participant sends each message to every other participant until they receive it) should be very doable, but I decided against implementing it for the release because it'd add quite a bit more complexity and would be rather tedious to test.
Your name is way too close to Tor Messenger which last release a few days ago shows very good progress.
Why this matters? Your project states that it's not secure. Their project aims at being secure. One person wanting security may inadvertently install your and end up being in a less secure state as what he would get with Tor Messenger.
Changing names following name space collision is no big deal... At the beginning ;) When your name is well known it's a total different matter.
Probably not, unless the DHTs the two of you belong to are connected somehow. For example, if the other person's seed server uses your seed server as a bootstrapping server.
12 comments
[ 3.9 ms ] story [ 36.8 ms ] threadToc is a project I've been working on for more than a year now. I'd love to hear what you guys think about it. =)
Toc is a proof-of-concept distributed messaging app designed from the ground up to support user data synchronization for use across multiple devices. It uses Telehash for its messaging stack, and is built on top of an Om-inspired architecture oriented around a central app state tree that gets encrypted using a custom encryption layer for persistence locally, and then synchronized seamlessly between devices using remoteStorage.
Originally, Toc started as our group's fourth year Computer Engineering design project at the University of Waterloo. After we graduated in May, I wanted to polish it up a bit before releasing, but evidently went a bit overboard and ended up working on it for another six months (albeit with a healthy dose of procrastination sprinkled throughout that period).
Toc is only a proof-of-concept, and has a list of awful issues that makes it rather unsuitable for long term general use. However, I'm hoping that by releasing Toc, we can bring more attention to the awesome technologies for building great decentralized applications that Toc uses, and inspire more developers to take another serious look at building distributed apps, as I hope we have demonstrated with Toc that a decentralized app can in fact have great UX if you design your apps with UX in mind from the start.
With that said, I am now officially looking for work. If you have any openings for a ClojureScript frontend project, or a React project that makes heavy use of functional techniques and immutable data, I'd love to hear about it. You can reach me through the email on my GitHub profile[1], HN profile[2] or through my Toc account[3]. ;) (disclaimer: that last option might not be completely reliable)
[1] https://github.com/lewisl9029
[2] https://news.ycombinator.com/user?id=lewisl9029
[3] http://toc.im/?inviteid=9b0d50b86dd596aa8c7a94bd116c2ed4a24f...
Is this the most advanced GUI Telehash Client?
Not sure about whether it's the most advanced... Toc's feature set is pretty sparse (text chat only) considering what Telehash is capable of. We do hope it's the most user friendly one though. =)
Of course, the Telehash version I'm using is very old and unsupported, so there's no guarantee that its integrated DHT can handle any significant scale.
All messages in the app are sent through channels that support an arbitrary number of recipients. That arbitrary number just happens to be always set to 1 at the moment.
A naive group chat implementation (i.e. an inefficient one where every participant sends each message to every other participant until they receive it) should be very doable, but I decided against implementing it for the release because it'd add quite a bit more complexity and would be rather tedious to test.
Your name is way too close to Tor Messenger which last release a few days ago shows very good progress.
Why this matters? Your project states that it's not secure. Their project aims at being secure. One person wanting security may inadvertently install your and end up being in a less secure state as what he would get with Tor Messenger.
Changing names following name space collision is no big deal... At the beginning ;) When your name is well known it's a total different matter.