I don't think you can simply "sell" customer information in the financial industry. It's a heavily regulated industry. RH can use information from the card to cross-sell its loans, if customers allow marketing communication. But I don't think they can just profit from allowing a 3rd-party access to that data. I never heard of a card issuer monetize their customer data that way. If you have an example, please do share.
I had a business partner/family member steal money from me in our business. It very much hurt and was a painful experience hoping for vengence. Perhaps SBF being distant from you is what makes you indifferent.
Yes that's fair criticism regarding my feelings, but GP feels the same and they had stolen $10K. So the distance from it can't be all there is to it.
I'm also pretty distant from a mugging that might happen today, but I find myself getting angry about it, so that also seems to contradict the theory that it's about distance (though to be clear, I largely agree with you and I suspect distance is going to be a factor for most or maybe the vast majority of people).
I guess you could say you don't need Amazon, the problem of getting goods is solved by physical stores. Yet, millions of people find value in ordering through Amazon instead.
There will be use cases where people simply prefer blockchain over the legacy alternatives because it's cheaper, faster or better and there will be "whole new world" use cases.
This is just more "handwaving with a bad analogy", which again only goes to show how hard it is for people to show any real utility for smart contracts.
It is very easy for me to explain and understand the benefit of ordering over Amazon vs. going to a physical store. When Amazon first showed up, I didn't think "Gosh, what is this really for?" or "Can somebody explain to me, simply, what Amazon is for?" No, I went to amazon.com, browsed a giant selection of books, ordered one and it showed up at my house a couple days later. "Wow, that's awesome" I thought.
If you say "There will be use cases where people simply prefer blockchain over the legacy alternatives because it's cheaper, faster or better and there will be "whole new world" use cases." then why is it so difficult for anyone to say what those use cases actually are?? You say it will be "cheaper, better, faster", but are able to offer no concrete examples or rationale as to why.
I’m speculating about how this works, but it probably doesn’t make sense for general-purpose email.
For emails between members of one workspace/domain, you can conceptually perform key exchange to implement client-side encryption. You also don’t have spam concerns within members of a workspace.
There’s no general way to do key exchange between different email domains, and you do have spam concerns (which to address requires scanning the content).
There’s no protocol for doing such things over different email domains in a way that’s compatible and interoperable across software stacks. This technology is proprietary, and would make spam challenging to deal with (which again is not a problem within one workspace).
It’s also not clear to me whether this is really client-side encryption, so much as encryption at a layer higher than the email stack. (It’s pretty hard to do client-side encryption in the browser, in a way that matches user expectations. How do you store/retrieve the encryption key?)
A number of Chrome (and I think also Firefox) extensions include their own local copy of OpenPGP.js for use with various webmail services, including GMail.
How does an email client use WKD?
1. A user selects a recipient for an email.
2. The email client uses the domain part of the email address to construct which server to ask.
3. HTTPS is used to get the current public key.
The email client is ready to encrypt and send now.
An example:
https://intevation.de/.well-known/openpgpkey/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4 is the direct method URL for "bernhard.reiter@intevation.de
How/where exactly does it store the user's private keys?
The initial reaction that I have to client-side encryption with a web browser is: how does the client fetch/obtain the encryption key? (For signing outbound messages, or decrypting/verifying inbound.) Local storage wouldn't be appropriate as the sole storage for something like an asymmetric keypair, and it wouldn't provide the behavior that users expect: being able to log in and use a service from any web browser.
No one interacts with a web browser in such a way that it would be appropriate for the browser's local state to be the sole storage of something important like a private key. So this necessitates a service that the client interacts with during login to fetch its private key.
If you can log in with a browser, then that implies that you're fetching the key from somewhere. In the context of hosted Gmail, then that means that Gmail will be storing and providing your key. In which case it's nominally client-side encryption -- and the system that stores and provides your key might be totally separate from the email systems (and tightly controlled) -- but it's still not what I'd think of as client-side encryption generally. It's not really client-side encryption if the service that you're using to store data is the same service (from your perspective) as the one that stores/provides your key (those responsibilities might be separated from an implementation perspective, but they aren't from a user's perspective).
The service can employ various techniques like encrypting its copy of my private key using a symmetric key derived from my passphrase (and then discarded) -- and this decryption could perhaps be done client-side in the browser -- but ultimately the service still has the ability to obtain my key (at time of next login, if not any time).
If the service that provides a client-side encryption key could be divorced from a particular use-case -- e.g., if I could use my own pluggable key-providing service with Gmail, which my browser uses to fetch my key on login -- then the model would make a bit more sense. (You'd still have to trust a service like Gmail not to steal your key, but at least you don't have to trust it to store the key as well.)
Would it be possible to implement a standardized pluggable key server model? It seems plausible. Imagine that there was a standard HTTP protocol for this purpose, kind of like how WebAuthN is standardized. I log into Gmail, link it to my key server <https://keys.jcrites.example.com>, verify the connection, and then when logging into Gmail, then the web page is allowed to make HTTPS calls to <https://keys.jcrites.example.com> to either fetch my asymmetric key, or alternatively make calls to decrypt or encrypt specific content.
In the former case, it implements client-side encryption using a key server I control, while trusting Gmail not to misuse the key; in the latter case, it implements encryption using a keyserver that I control, and makes remote calls for each encryption operation. In that case Gmail would never have my key, although while browsing Gmail.com it could probably make arbitrary requests to the key server to perform operations using the key -- but you could log what operations are performed.
...I might counterparty that, just because Michael frigging Liberty got one, and if I did, Murphy would almost surely conspire to keep it from happening, on account of the favorable outcome for me at stake.
Then again, I try not to tempt those that should not be tempted.
Unfortunately IRC has failed to keep up with the U/X of centralized chat services like discord which is a shame because an open protocol chat seems needed for the internet.
I would say the opposite rather, the UX of IRC clients (eg, HexChat) is so polished and refined, it puts all the proprietary chat services (and their clients) to shame.
> Why does open protocol usually mean crippled U/X?
Open is entirely unrelated to that, but optional features means crippled UI/UX in the long run. Some server won't support it so users can't use it, or some client won't support it so they will see garbage/nothing when others use that feature.
XMMP showed that well enough and it seems IRCv3 follows suit.
FWIW TheLounge [1] and Convos [2] can front-end an IRC server giving it much of the look of a modern client and also chat persistence when using TheLounge in private mode. The trade-off in my opinion is scalability. With a bog standard IRCD I can handle tens of thousands of clients per node. Adding web persistent increases memory usage.
In an ideal (and therefore unrealistic) world, it would be done by the UX designer/dev equivalent counterparts of the ones developing these open source softwares.
Why do low level engineers work freely on FOSS but designers or UX devs don't is the question.
Proper UX designers would be ridiculed in the FOSS world because everything is bloat or too corporate. If it doesn't look like Windows XP or a 70s terminal it isn't welcome in FOSS.
Gnome is probably the best example of good design in the FOSS space and look how people talk about it. Even in this thread you have people claiming being able to view images and video inline in a chat is an "anti feature". Can you imagine trying to design a product for people so detached from reality?
Because they have different opinions doesn't mean they are detached from reality. IRCCloud shows images in the feed, for instance. I just like the fact that I don't need that overhead in my client if I don't want it.
There should be a way to decouple the UX from the program and if people want a Discord “skin” for IRC that looks nearly 1:1 they should be able to have that.
I don't think that would help. The IRC protocol is missing so many messaging features that platforms like Discord have. Just looking like Discord wouldn't fix that.
This is lipstick on a pig. I'd be perfectly happy with a client that looks like IRC but has the features of Discord. I'd like to be able to chat on my phone without running an external service that provides a modern HTTP based protocol.
IRCCloud is fine, but it's more expensive than Discord, the UX is not quite as nice for reasons inherent to the IRC model, and it's not really more open in any substantive sense (my phone will be running the proprietary IRCCloud application that speaks a proprietary IRCCloud protocol). So why would one bother?
> and it's not really more open in any substantive sense [...]. So why would one bother?
Not for you, because you want to use a turnkey solution, and you don't want to pay for it (instead relying on whatever model they have where you are the product, I guess?). But if you use IRC to talk to me, I can run my own bouncer for free, and I can run the client I want. I can even write my bouncer and my client, and still talk to you.
That's infinitely more open than Discord. It's just that you don't care about others.
> Not for you, because you want to use a turnkey solution, and you don't want to pay for it (instead relying on whatever model they have where you are the product, I guess?). But if you use IRC to talk to me, I can run my own bouncer for free, and I can run the client I want. I can even write my bouncer and my client, and still talk to you.
> That's infinitely more open than Discord. It's just that you don't care about others.
I care a bit about whether you can run your bouncer. But I also care about whether non-technical people can talk to me without an unreasonable level of effort. Expecting everyone else to pay extra for a worse experience so that you can use it the way you want seems pretty entitled.
> Expecting everyone else to pay extra for a worse experience so that you can use it the way you want seems pretty entitled.
Yeah, the price is an issue indeed. I guess that's why we keep having monopolies: it's easier to get VC money if you can ensure user lock-in, and it's easier to make a nice UX if you have VC money.
Now, don't think you don't pay those proprietary messengers. You just pay differently.
Irssi's UX is better than that of any other chat software, though. Why it hasn't been replicated for things like XMPP and Matrix is probably due to the more difficult and featureful state transitions of those protocols.
I switched over from irssi to poezio a few years ago (with a self-hosted biboumi as XMPP<->IRC gateway) and I don't miss irssi (anymore).
Of course, the transition was a bit bumpy, but I think that'd go both ways. As someone else said, it's not a direct replica. Yet, it feels close enough and not too close for the uncanny valley.
There are several XMPP clients trying to replicate -more or less freely- the same experiences, such as poezio [1] or profanity [2]. YMMV of course, and nothing will be a carbon copy of irssi, except if you use a plugin (but in my experience bolting another protocol on top of a client for another will result in a poor UX).
I do believe there are TUI clients for Matrix, but I am unsure of their maturity and state, or how they compare to Irssi.
Do any IRC clients support inline media upload/viewing, profile pictures, voice/video calls, or replies/threading? These are the things I would consider the core essentials of IM. Any serious platform has all of this plus a whole lot more.
The web front-ends multi-user clients I linked in this thread support file sharing, image uploading. For voice one could run either uMurmur or Murmur that also provides text and voice chat. People can be given permissions to create channels on Murmur whereas uMurmur you static define the channels as it is meant to run on home routers. There is a phone client for Murmur called Mumla. Murmur also supports file sharing but it was not really optimized for that to be used by a large number of people at once in my opinion. The voice quality of the OPUS codec is incredible. Open source video chat would likely be Jitsi and is a bit more complex.
These are not all-in-one solutions yet and certainly not as low-friction as most would prefer. I expect development to improve in all of these platforms as the centralized platforms go through growing pains and buy-outs.
Even then I would not expect everyone to migrate to these self hosted platforms and in a way I actually hope they do not or those platforms may get the unwanted attention from the powers that aim to protect us from our speech.
I think I would leave any platform that added most of these and that it is better for IRC to stay as-is so people like me have places to chat. People like you already have Discord/etc.
So to get all or some of those features you can use IRCCloud. Is it the same as IRC having those features?
I could (and do) access IRC over Matrix and then I also have access to those features. But in this case also users not using the same client or same server as I am get to see those things.
> Do any IRC clients support inline media upload/viewing, profile pictures, voice/video calls, or replies/threading? These are the things I would consider the core essentials of IM. Any serious platform has all of this plus a whole lot more.
Media upload is purely on the client side. If IRCCloud lets you to drag-and-drop an image, uploads it to some server, and then sends the URL, then that's still entirely IRC (I will receive the URL), but IRCCloud is making it easier for you.
Same for viewing content: I send a URL, and your IRCCloud will show a preview (image/video), while my client won't. That's purely on the client side.
For voice and video calls, IMO I don't want it in my messaging app. I can use my browser for that, or a dedicated app. And again, share a link to my videoconference over IRC.
Replies/threading are a tricky one. I hate the replies in Discord, and I don't really get threads. I see Slack channels where the rule is "answer only in threads", which to me says that they want a forum (like Discourse), not an instant messaging app.
> But in this case also users not using the same client or same server as I am get to see those things.
Pretty sure that if you use replies or threads in Matrix when talking in an IRC channel, then people on IRC won't see them as replies or threads.
> Pretty sure that if you use replies or threads in Matrix when talking in an IRC channel, then people on IRC won't see them as replies or threads.
Replies are rendered to IRC with a prefix indicating what they're responding to, but people from IRC cannot "reply" (though maybe some ad-hoc protocol could be devised for this). I don't know if threads are handled the same way, but I assume they are. Of course you can't really bring either of these features to a platform that doesn't support them without modifying the platform.
By "other servers" I meant other Matrix servers, as it is the system that natively supports the features.
