The name is awful. What it stands for anyway?
Trust? Doesn't seem all that diffcult, especially with some marketing. Are you trying to say that Facebook and Twitter are better names?
Trsst: a distributed secure blog platform for the open web
21–30 of 58 posts
Re: Trsst: a distributed secure blog platform for the open web
#22Their screenshots are of twitter.
Our use cases are of Twitter too, so it makes a certain sense. We haven't designed the UX yet, but it's meant to convey the idea. That said, the architecture supports not only Twitter but FB-style friending and private group shares; we want to encourage different clients in different form factors, with the advantage being that they'd all interop. No more siloes.
Yeah, sorry, all of that is irrelevant. You use somebody elses UI on your kickstarter. That is a terrible, terrible idea.
It's an idea terrible enough that it will make people doubt your competence. For me, personally, "building strong crypto" and "lifting the twitter UI because too lazy to whip up some visualization of a simple roadmap" don't go together.
Re: Trsst: a distributed secure blog platform for the open web
#23Earlier quoted context omitted.
I hope you at least consider a java client as well, so there will be one implementation that is actually usable - as javascript and crypto doesn't mix (unless something is happening wrt api-support in the various engines/browsers? But then I guess you'd say html5, not "javascript"). Should be much quicker to develop a common library for use by the server and a (webstart) client - than to do two separate implementatio…
If normal people are going to use it, it has to run in a browser, hence JS. There are working open source crypto libs in JS today, and kind of the nice thing about them is that they're not compiled, so (if unobfuscated) you can literally just inspect the source. That said, we plan to generate keys like bitcoin does, so there if you have a bitcoin library in your language of choice, that part is done. The server code…
No, you can't. It's a pervasive and harmful meme that JS crypto code is easy to inspect. But it's not:
* If 100 different users are served the code, it's easy to pick 1 unsophisticated user out and serve them something different.
* Even if your users are sophisticated, they effectively have to install the code every time they use it, so any inspection they did yesterday will help them not-at-all today
* Browser Javascript code is influenced from all sorts of places across the DOM, meaning that you need element- by- element, attribute- by- attribute inspection of the entire page context (and this is before we get into things like caching) to have any clue what a piece of JS code might be doing
* The browser itself offers you no mechanism to hash and verify the whole runtime, so there's no way to lock in a specific inspected cryptosystem; even if you have the SHA2 hashes for your crypto .js, you won't have it for every point in the DOM that can override methods in that code
Leaning on browser javascript for cryptography is a bad idea that, I think, shows a fundamental disrespect for the security needs of actual real people who will be fooled into relying on it. I strongly advise you to go in some different direction.
Re: Trsst: a distributed secure blog platform for the open web
#24What programming language do you plan to use for the reference implementation?
JS on the client, and that's the important bit where all the crypto happens. Likely Java on the server, basically a drop-in servlet for any Tomcat, but still TBD.
Likely? So you don't even have a solid plan how to build your app?
Re: Trsst: a distributed secure blog platform for the open web
#25The name is awful. What it stands for anyway?
Play on the word trust + rss? tRSSt?
Re: Trsst: a distributed secure blog platform for the open web
#26Earlier quoted context omitted.
JS on the client, and that's the important bit where all the crypto happens. Likely Java on the server, basically a drop-in servlet for any Tomcat, but still TBD.
Read "JavaScript Crypto considered harmful" http://www.matasano.com/articles/javascript-cryptography/
Gah, HN is rate-limiting my responses.
Very familiar with the document, but it mainly just boils down to watch-out for XSS attacks. We require SSL to deliver the entire page with no external libraries or references. His response to this doesn't really say anything. See: "WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT CRYPTO CODE?" We need the crypto for keygen and signing and encryption, so he's missing the point completely.
To the other point made above along the same lines, the protocol is the key and you are free to choose your own client. No matter which you choose, you have to trust the source.
Our goal is to get the protocol adopted and used as widely as possible. Mass adoption is only possible if there's a web client with JS crypto, and there's no way around the need to trust the server you download it from.
Re: Trsst: a distributed secure blog platform for the open web
#27Looks like you posted this back on 8/18 as well. I guess you can get around the rules by adding/removing a # from the URL.
Re: Trsst: a distributed secure blog platform for the open web
#28The name is awful. What it stands for anyway?
Trust? Doesn't seem all that diffcult, especially with some marketing. Are you trying to say that Facebook and Twitter are better names?
I'm not trying to say anything besides the name is not really good IMO.
But since you bring up, Facebook and Twitter are way better names.
IMHO it is not a good name because: * Not obvious at first glance that means 'trust' * How do you pronounce that? just say 'trust', spell it or try to say it in some bizarre way with a mute 't'? * Doesn't look pretty
For me the only good thing about the name is that is unique.
Re: Trsst: a distributed secure blog platform for the open web
#29'decentralized' yet needs $15000 PA for server hosting?
Re: Trsst: a distributed secure blog platform for the open web
#30Earlier quoted context omitted.
If normal people are going to use it, it has to run in a browser, hence JS. There are working open source crypto libs in JS today, and kind of the nice thing about them is that they're not compiled, so (if unobfuscated) you can literally just inspect the source. That said, we plan to generate keys like bitcoin does, so there if you have a bitcoin library in your language of choice, that part is done. The server code…
No, you can't. It's a pervasive and harmful meme that JS crypto code is easy to inspect. But it's not: * If 100 different users are served the code, it's easy to pick 1 unsophisticated user out and serve them something different. * Even if your users are sophisticated, they effectively have to install the code every time they use it , so any inspection they did yesterday will help them not-at-all today * Browser Java…
Shrinking that to a sound-bite: JS crypto is the NSA's wet dream.