Hacker News new | comments | show | ask | jobs | submit login
Trsst: Proposed distributed secure blog platform for the open web (kickstarter.com)
42 points by sinak on Aug 17, 2013 | hide | past | web | favorite | 13 comments

Ever since Bitcoin and PRISM became 'mainstream' so to speak, I feel as if the renaissance period of P2P/decentralized communications has been kicked off. This last couple of months I have seen so many projects for decentralized and secure communications, but they all are individual in their own little communities, and it's sad to see such a fragmented space.

Now, to comment on the actual project. It seems here that we have another person attempting another decentralized project with a vision but no planning. It can be done, as somewhat shown by Tox [1] which was started off a /g/ thread on 4chan, but I'm not liking it so far. Generally you either start with some innovative ideas and get people to help you develop them, or you develop something and get people to help test it. Nonetheless, I wish the author the best, as we have similar goals.

On this note I'd like to end with a plug for my project [2], which is somewhat similar to Trsst but uses a P2P publish-subscribe overlay for distributing messages (it's more of an experiment than a product).

[1] - http://tox.im

[2] - http://bitweav.org

Thanks for your efforts. Others are working on similar projects.

I'm not sure whether this applies to liamzebedee's concepts (haven't read enough yet) but may apply to the trsst scheme: I just want to point out that there are really three problems to be solved:

(a) prevent unintended parties from reading messages - this is handled as well as can be (as far as we know in the present state of things) by strong encryption. It also requires avoidance of reliance on third parties such as CAs.

(b) correct identification of intended interlocutors - I believe the CA system, and any central-"authority" system, are worse than useless for this. The only alternative that has a realistic chance at the objectives is a "web of trust" based on side channels, individual judgments about who's who and who's controlling their own keys correctly, and watching keys and behavior of parties for consistency over time.

(c) obscuring who's talking to whom. If Alice publishes something on trsst, encrypted for Bob, it may be unreadable by anyone but Bob (assuming 'a' and 'b' are sound) - but if the adversary Nancy has extensive, sophisticated powers throughout the network, then Nancy may be able to track the posting of the message to Alice and the reading of the message to Bob. Then Nancy can track them down and coerce their secret keys, trojan their PCs, or "disappear" them (not in USA, you say? wait for it).

If I'm reading this correctly it handles (a) and (b) to some degree but I'm not sure it addresses (c).

I feel like people keep trying to build distributed applications from the ground up, rather than building distributed infrastructure that applications can be built on top of and share.

Well, the systems are being developed (cjdns/namecoin etc), but I haven't found any yet that I look at and think, wow yeah, that's usable and could work at Internet scale, I can see that installed and in use on my mums computer.

If I'm building an application to allow two people to chat with each other in a p2p fashion, I shouldn't have to worry about how the two chatters will be able to find each other and set up a secure connection. I should just be able to call some OS level API to specify, "try to establish a connection with Person x to use with chat service Y"

Basically, we need a way for hosts/people to find each other on the Internet and to exchange keys securely. If/once we have that it will be natural and easy to build any sort of p2p application.

I'm working on this along with others. Essentially, it's the infrastructure needed to build secure, distributed applications and deals with the problems of identity, connectivity and sync. It needs to be open-source with a permissive licence, otherwise it becomes just another silo.

My view is that once the infrastructure is working, we need to start with the core applications of mail, contacts and calendars. Ultimately we can create a platform with something like a distributed app store that makes it easy to use the infrastructure and get it out to end-users.

I'm putting together a website that describes the pieces but if you want to know more before then, please send me an email (see profile).

dtby: Your comment is hidden as you're account is "dead". I realise you already know this. I would be interested in seeing what you've built... Contact details are in my profile, or you can reply here again.

It sounds like what you want is "CaaS". Connectivity as a Service. Specifically, connectivity that allows unrestricted two-way communication between end users. "Unrestricted" as used here refers to restrictions arising from firewalls and NAT.

This sounds simple enough. So why isn't it a standard offering? Only the connection. Not the connection as part of an application that uses the connection. Only the connection on its own. IOW, what you see when you type ipconfig or ifconfig. A connection that can then be used by any application. A user might use have some applications use this connection (i.e. interface), but not others. Her ISP-provided connection to the Internet and her CaaS connection to a small user-created VLAN overlay network can be separated on the logical interface level. One way to envision this is the CaaS provider gives the user what she needs to make her own small overlay networks. App developers might provide LAN-based applications to run on top.

Everyone reading this online has connectivity to "the Internet".

But the vast majority of end users do not have connectivity that allows unrestricted two-way communication with each other.

Instead they must communicate through a third party such as an email provider (e.g. Gmail) or a website (e.g. Facebook). Firewalls allow ingress traffic coming from such third parties. Those third parties generally monitor and often analyze all traffic that passes through them, usually for commercial benefit. Perhaps they store it as well.

Regardless of the security or privacy implications of this model, communication via a third party is often inefficient. Why should two users in the same country who wish to send data to each other be required to send their data to a datacenter in a different country in order to communicate?

To take but one very basic example, consider email. What if end users ran their own SMTP servers and these servers communicated directly? There would be no need for "email providers". This is not so far-fetched as it might sound. In the early days of the Internet, there were no commercial email providers acting as "gatekeepers" of email, as there are today. And if you go back far enough, there were also no domain names nor centralized pseudo-authorities (ICANN and its "authorized" registrars), who constitute an additional gatekeeper. As it stands today, you generally need both a preferred IP address and a registered domain name to reliably send email, not to mention the permission of your ISP. There was much less centralization and control in the early Internet and it was far more fun (and I would argue far more useful). Email users could communicate based on mailbox name and IP address, and without involving third party SMTP servers. Imagine the simplicity.

Connectivity as a Service could make decentralized, user-controlled email again possible for subscribers of different ISP's. It could also make many other otherwise "impossible" Internet uses possible. I posit CaaS could increase the value of the Internet as a whole.

Internet centralization and its incumbents may be ripe for disruption. We might innovate toward more decentralized uses of the Internet than centralized ones.

Then again, CaaS may not be what you want. I may have misinterpreted what you were describing.

It is hard to kick off because for various reasons a lot of end user communication is done on devices locked to various vendors and with software that is "curated" all while the net neutrality has taken a beating in recent years.



I love this idea. A few questions about implementation:

- What is the central source of truth for names/identities?

- I assume the primary consuming client will be a web browser. Will content be decrypted client-side in the browser, or is one's server node implied to be trusted? The latter could be a security risk.

- Are there any constraints on message sizes, and can files be attached? If messages are limited in the blogchain, can they be "stitched together" for longer posts?

Like others here, I love this idea; a similar concept has been bouncing around in my head over the past few months in light of NSA-related news.

But the thing I keep coming back to in my head is, "how do we get people who know nothing about encryption, or even care that much about being monitored, to use more secure channels?"

When I saw the title of this thread, my first thought was, "how could we build something that allows people to run WordPress--already open-source and used by millions--on a distributed secure network?" How could we make 'distributed and secure' easy and stupid-simple for anyone who already knows how to install and use WordPress (or any other open-source software for that matter)?

I feel like we're trying to build things from scratch when building better wheels is more practical for the masses who already have vehicles they're comfortable driving.

[Edit: FYI, the video on the Kickstarter page makes trsst sound a lot more like a 'social media platform' than a 'blog platform'.]

The usability question is crucial for secure comms on a NSA-infested internet - it must be "easy" for non-technical people, but such as to not obscure anything, nor impair configurability, for more astute users.

But usability is a posterior issue. The first thing is to get the principles right, then usability can be applied by putting on the right interfaces. And I don't think there is any consensus about a good design yet. See my reply on another comment about the design of this system.

  We develop organically: first, we get it working; then we get it working right.
The approach to writing security software which launched a thousand defcon talks.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact