

Trsst: Proposed distributed secure blog platform for the open web - sinak
http://www.kickstarter.com/projects/1904431672/trsst-a-distributed-secure-blog-platform-for-the-o#

======
liamzebedee
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](http://tox.im)

[2] - [http://bitweav.org](http://bitweav.org)

~~~
mike-cardwell
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.

~~~
gwu78
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.

------
lukifer
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?

------
raamdev
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'.]

~~~
ds9
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.

------
ctz

      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.

------
unicornporn
Related:

[https://tent.io/](https://tent.io/)

[https://tent.is/](https://tent.is/)

