GNUPG is a horrible pile of shit currently in the process of being rewritten by tmsr. I wouldn't want it reused ; I suspect most of the "good things" are in the same situation. If you read the logs for the past coupla years you'll see we had started from your position, and slowly discovered that no, the stack is rotten to the core, and almost everything's either entirely useless or in need of a full rewrite.

There's XMPP, there are ways to do end-to-end encrypted group chats (e.g. what open whisper systems do (mpOTR has too many unresolved flaws iirc)), etc. Not to say that this would need to stick to XMPP in some way, but, dunno, keep it simple / reuse good things. Perhaps just interface with gnupg, generate a keypair, and use gnupg for encryption/decryption/signing; and do some very simple/straightforward content GETing / POSTing. Group membership info may be stored on server. Doesn't sound too bad of an approach. If one were to demand higher integrity/authenticity promises (in regards to e.g. group membership info stored on server), one could think of employing a public ledger for this kind of stuff.

See, thinking about it any way you wish, the upside of using a browser (random lazy derp can just go to an url) is not really a match for the upside of using a dedicated app (you can use p2p distributed hash tables for crying out loud!).

There's just no life in this idea as originally thought out, a browser thing.

> I take it you mean

That, at origin, a lot of subsequent discussion in the forum hence, refining etc. Even yesterday.

> So someone is working on gossipd I take it

The person named has been awol for a while. But it's not fair to say people aren't working. Currently the cud of the thing is being chewed.

> Wait, what ? Admittedly I'm no javascript expert, but you could obviously shasum all the files that get loaded and have samples up for display ?

Of course, (technically) yes, however, from an actual user experience perspective, I think this "being able to shasum and compare against signed samples or whatnot" feature is not as useful as you may think it may be: if there is no way for the *browser* to pin a resource (which essentially means "trust the server first time I load the page, hash this thing and then alert user if hash has changed, and do not execute automatically in that case"), it's still dangerous. Consider that (by virtue of the whole browser stack being so fucked) when you open a page with JS in it, you're kind of "installing" and running a new app every time you load it.

If I go to a page and my browser (being the steaming pile of shit that it is) automatically runs all it cans (seriously: did you know that browsers may attempt to eval() a file if file type is unknown, *hoping* it may be JS (and doing their discovery process this way)?? - see bashing by one James Mickens, systems engineer: http://scholar.harvard.edu/files/mickens/files/towashitallaway.pdf ), it's sort of useless if I later discover that, wait, shasum mismatch, I just executed shitty JS code. Now, I can make my browser not do that (auto execute), but I don't want to manually compare checksums every time I load a page, either.

Can check on browser extensions etc etc, but the point is, it's nice if you can tell the browser to only trust this particular version of the file, and warn you *before* it gets any funny ideas of executing it - just that. W3C appears to have standardized such enforced resource pinning. Using this in addition to samples, and say, a nice signed message with hashes in it may be enough. (But if you run an older browser which doesn't give a fuck what it's served, god help you! But then it's your fault anyway, so.)

> gossipd

Yeah, maybe it does. I take it you mean http://trilema.com/2015/artifexd-a-better-ircd-rfc/ - interesting proposal. I wonder if you'd still think doing a JS version of the social site to be worth it? I stumbled upon this particular post sort of accidentally, after looking for frontend-based discussion board implementations. I'd imagine an implementation for a more generic public key + encrypted blob system, with such a BDSM community social site being a further customization of that system. Having the latter in decent less-shitty form would surely be nice.

> The 35 exponent.

Hah, oops, well fuck. Gonna check it (Phuctor and its findings) in more detail, this is entertaining!

> Cramer–Shoup

Aha. RSA seems the way to go as of now, then.

> RNG in JS

Yeah, fuck that shit. Web crypto API (standardized browser API) may be the way to go here (https://developer.mozilla.org/en-US/docs/Web/API/RandomSource/getRandomValues e.g.), but it still feels dirty.

>> Symmetrically encrypt local cookie data with a passphrase stored on the server

> So you've just de-rsa'd it.

Yeahyeah, this breaks the initial idea. (Private key would still not be handed to the server, note; but this would have implications for dependence on particular server as well as some form of legal deniability on the server's part...)

Re. all else, gotcha. So someone is working on gossipd I take it - interesting.

I'd still like to implement this. I don't know - maybe doing all of the above in the browser *is* futile and prone to disaster. Possibly it's still a worthy idea, I think.

May have further follow-up points later on.