381–390 of 397 posts
Earlier quoted context omitted.
The timeline is missing the fact that ICQ converted to Oscar after the AOL acquisition and users on both networks can talk.
Thanks - will fix.
Earlier quoted context omitted.
Our encryption is based on Java and everywhere we check buffer overflows and possible timing-attacks. Hopefully we use AES and SHA256 that is easy to validate. Also Instead of using N code bases (one for each platform) we reduce it's amount by conversing sources from java to other languages for every platform. US-based encryption is taken directly from BouncyCastle, time-proven library for Java. Russian implementatio…
Ok. But why use AES and GOST? AFAIK they're both based on feistel networks? If one were to layer two symmetric encryption schemes today I'd think one would go with something like salsa[ed:chacha] and keccak (in authenticated encryption mode) -- and it would probably still be a bad idea, adding much more complexity than security? [ed: Oh, and here I go, proving that non-cryptographer should be careful about what they…
Earlier quoted context omitted.
Care to share your webpack config for getting React and TypeScript to play ball? I'm collecting a bunch to try to figure out what works best.
That's actually interesting topic :) Right now we use gulp and gulp-typescript. So far, I like approach that is used in https://github.com/Microsoft/TypeScriptSamples/tree/master/e... but I'm not sure if we are going to use it any time soon. As far as gulp config, what we use is pretty much close to gulp-typescript README examples
A hundred different chat systems mentioned here. None of them compatible with one another. Well, I guess a couple of them have IRC gateways, but you have to actually set those up. Gee, wouldn't it be nice if you could pick and choose your UI? Pick and choose your "integrations", your "plugins", your client, etc without having to lose your entire userbase, history, contacts? Some sort of open protocol. Urgh, I've been…
I might be alone here, but I don't see the problem. I also do not believe that federation or interop would be a good feature for group chats. You want to pick and choose your UI? That is an anti-feature. One user sends an image and the other cannot display it because he uses a terminal client. One user sends an emoji, another client only displays a box, because he has no glyph in his font. This is already a problem w…
That argument is like saying we should only have one HTML browser because text-based browsers like w3m could exist.
And "one user sends an emoji, another client only displays a box, because he has no glyph in his font" is an issue between different operating systems. Even in a non-federated system like Slack I used to get emojis from people using iOS8 that don't display properly.
Earlier quoted context omitted.
People do care. I'm working on a Qt Matrix client for KDE / maybe eventually Telepathy. The problem is non-techies do not understand why email is good while messaging is bad. There is no indication as to where these problems would come from, and they have no insight into why the problem happens in the first place, while they gleefully eat up iMessage / Facebook Messenger / Skype / Hangouts / Whatsapp.
Because to a non-techy, running a messaging server is just as out of reach as running a mail server. It's just too difficult.
https://xmpp.net/directory.php
Similarly how it's done with mail.
Earlier quoted context omitted.
Prefixing a date/timestamp unless the client has asked for IRCv3 timestamps is reasonable.
And now, you just broke essentially all clients that already support channel logs by duplicating anything they already had. This is a problem bouncers are already solving best they can, and it still sucks. It's not good enough to compete with slack.
I didn't say anything about competing with slack.
Email's pretty crappy but at least with email I get small, contained threads of conversation that can be searched and organized easily. Slack is like having a few giant never-ending email threads. It's horrible.
And there's still no voice.
Earlier quoted context omitted.
Our encryption is based on Java and everywhere we check buffer overflows and possible timing-attacks. Hopefully we use AES and SHA256 that is easy to validate. Also Instead of using N code bases (one for each platform) we reduce it's amount by conversing sources from java to other languages for every platform. US-based encryption is taken directly from BouncyCastle, time-proven library for Java. Russian implementatio…
You're not helping your case. You make it sound like you are using bricks without knowing what their strength is. It's a bit like saying you made a boat out of wood for buoyancy and filled it with sand in case the wood catches fire. Sure, a plank of wood doesn't sink, but too much sand can make it sink, and sand won't be of much help if there is a fire. A wooden boat is better than one filled with sand. I'm not sure…
Earlier quoted context omitted.
Only as inane and uninteresting as the comment you just posted. You can't impute motives why someone might ask that question. You may feel it has been repeated ad nauseum but it's quite possible those asking the question haven't read the previous HN comments. At this point, you come over as an arrogant jerk.
Ask a silly question...
A hundred different chat systems mentioned here. None of them compatible with one another. Well, I guess a couple of them have IRC gateways, but you have to actually set those up. Gee, wouldn't it be nice if you could pick and choose your UI? Pick and choose your "integrations", your "plugins", your client, etc without having to lose your entire userbase, history, contacts? Some sort of open protocol. Urgh, I've been…
We are actually trying to make open protocol in https://actor.im with federation with https://matrix.org . It seems that only Actor and Matrix understand importance of federation.
How do other servers know how to reach me?