11–20 of 58 posts
Their screenshots are of twitter.
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.
What 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.
Should be much quicker to develop a common library for use by the server and a (webstart) client - than to do two separate implementations? Also some of the code (and most of the interfaces) could probably be used on Android as well.
If you are doing javascript wouldn't nodejs on the server make sense?
Earlier 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.
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…
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 will probably be less useful because there are so many choices, everyone's got their own preferences, and the server is pretty dumb compared to the client. Our leaning is to go with apache tomcat mainly because it's apache and it's widely deployed and, not least, it's what we use.
Earlier 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.
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…
Still, if anyone has mission-critical privacy they want to protect, we expect there will be hardened native clients to choose from.
Most posts from most people are going to be public anyway. We keep the public stuff public, but signed and search-indexable, and we let you do private stuff securely if you want to.
Earlier 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.
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…
Earlier 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…
That said, the js crypto isn't the part I'm worried about. It's all the scripting vulnerabilities to guard against in the browser. Still, if anyone has mission-critical privacy they want to protect, we expect there will be hardened native clients to choose from. Most posts from most people are going to be public anyway. We keep the public stuff public, but signed and search-indexable, and we let you do private stuff…
Just like how sending a gpg encrypted email to (some) users of hushmail wasn't secure, because in the end hushmail encouraged insecure handling of the private keys.
In the end, the only rational, informed choice, is to regard the whole system as (in)secure as its least secure part.
If there is to be any point to a "secure social network", the trust you can place in the network (implementation) should be at least as high as the trust you place in those you share with?
Will you be able to take reasonable steps to prevent private keys to be written to (unencrypted) swap, for instance?
Promising a "secure" social network, kind of implies that data you share is secure from your spouse, for example.
What 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.
What it stands for anyway?
Horrible name - please change it. People are going to have no idea how to pronounce that. Just because you were able to get a 5 character .com domain name doesn't mean you should use it for your new venture.
But I get your point, it will need some marketing to get people to understand what it is all about. But it's not like we knew what Twitter was at first. Did we?