While the updates here are good, the bigger thing I'm surprised they aren't addressing is spam messages requiring attention.
Just split the messages into folders of "people I have contacted and/or whitelisted" and "Strangers". Any incoming message of a non-whitelisted person or someone I haven't contacted previously should not trigger a notification and should be nothing more than a notification bubble in the folder with a number of unread messages.
This means that I only forced to deal with messages by known people, and when I get bored I can peruse messages from strangers and decide if I want to deal with them or not.
Yes. I am 100% in sympathy with the people who are concerned about unwanted messages and team adds, but the nuclear option at the bottom of the post seems to cover it:
> `[ ] Only let someone message me or add me to a team if...`
The only thing I can think of that would be better than this would be to enable this by default.
It's fascinating that the two example spammers in that post have women personas, whereas a huge chunk of the problem is men (generally actual men, not fake personas) trying to hit on women. It's not clear to me Keybase believes that's actually a problem or, as the original article says, working as designed.
Sure, but, is that Keybase's problem? Keybase and Instagram are very different apps with very different target audiences, and Instagram didn't have an uptick in unwanted messages after changing their user base via a a cryptocurrency drop. (See also jakelazaroff's subthread.)
If Keybase, an app that is (or was) about encrypted messaging and replacing the PGP web of trust with something more meaningful, is assuming their spam problems look like the spam problems of Instagram, they are probably going to solve the wrong problems.
There's two senses of "worse" that you could mean. If you mean "it is worse to be on the receiving end of the first than the second," then I think that's an accurate statement of my beliefs, but I don't think it's super relevant. The claim I'm making is "There is a worse outbreak of the first on Keybase than the second," which is a testable claim (that I might be wrong about!).
Keybase seems to be enjoying an identity crisis. On one hand, it’s a tool that makes a lot of sense for team collaboration, particularly with its low-effort encrypted git implementation. I even know a couple teams doing software development for the US government using Keybase for collaboration.
On the other hand, the Stellar (cryptocurrency) wallet and the “feature” referenced in this article are something... else. Granted, Keybase is $0/month per user currently, so it’s no surprise it is the founders’ personal sandbox for experimentation.
I thought Keybase were on the right track in the past with their feature conservatism. Now, not so much.
Feature conservatism has never been Keybase; their identity crisis has been going on for quite some time. What first started as a simple messaging app became a file-sharing service, then a Slack competitor, and now a cryptocurrency wallet.
Adding a simple toggle to block unsolicited messages doesn't sound like too much in that respect.
As far as Keybase is concerned, I can't complain when a company sends me free money every month—I'm up to about $60 USD now and there’s another airdrop next week.
I think we're just at the beginning of the integration of messaging clients + digital currency—you know if Facebook’s Libra gets off the ground, people will be using Facebook Messenger to send it around.
I feel like the #1 thing they ought to be doing is opening it up as a platform.
I think their original mission was: build a better keyring. They've done that, it works great! But the idea that they will follow that up by building a chat app better than Slack or Teams seems like hubris, akin to trying to win two roulette spins in a row.
If, OTOH, they opened up KB as a platform, I'm not sure what exactly would happen, but it could be pretty cool. It's not hard to imagine, say, a distributed social media app built on exposing a feed of files your KB friends have posted in their public KBFS, or indie game devs using Keybase as a cheap and fast way to add authentication and in-game chat to their games. I'm not sure how they would monetize that exactly, but it seems like a better problem to have than "let's beat Slack and Teams with five developers and a several-years-late-start".
And the ability to view multiple channels / chats at the same time, please, for the love of productivity.
How has this been omitted for so long? I used to be able to have multiple IRC channels open at the same time. Now, gotta switch back and forth on that slow Slack UI.
You don't need to win the market if the market has billions of users. Keybase has a few million users, doesn't it? Get 40% of that to use it, and you win.
It is somewhat unfortunate to watch what's happening to Keybase. I read /r/keybase over on Reddit and every single post is whining about how they didn't get enough free bullshitcoins or how some people are exploiting the system to get too many free bullshitcoins. It is the highest concentration of whining I've ever seen on the Internet... and I read my own posts ;)
I think there are some fundamental conflicts that are going to be difficult to resolve. Back in the old days of the Internet, everyone could message everyone else. This was great, except for all the spam. Ultimately, by putting our email in a central place, capturing the text of every email message, and analyzing it, we got a world where you could use email and largely be free of spam. But it did come at a great privacy cost; the same access that allows ML to categorize your email allows anyone to read your email; server administrators, hackers, law enforcement.
(This problem plagues every open network, not just email. You are not the only one that gets 6 phone calls a day about how Microsoft needs to be updated or the Internal Revenue Service will come get you, or something.)
This all blows up with end-to-end encryption. There is no centralized place for messages to be classified, so no spam filtering can be done. It is the wild wild west. The mistake I think Keybase made was not realizing that having easy discovery AND private messaging was going to result in a lot of spam. You can have easy discovery and then analyze every message to make sure it's not abuse. Or you can have great privacy, and require everyone to exchange a 1024-bit secret key in person before they can talk to each other. Keybase has a kind of middle-of-the-road approach that is the spammer's dream platform. You can find all the information you need to message me right on my HN profile, and I can't do anything to stop you.
They also made it worse by giving people free money. Now people are conditioned to think that a message announcing they just got some free money is legit. (The first I heard about the airdrop thing was when I had received my first drop.)
You hate to see it, but I think that secure messaging and showing your investors exponential growth are basically mutually exclusive. As long as Keybase pays people to have their account open, they'll have users... but I wonder what their plan is after that.
> Ultimately, by putting our email in a central place, capturing the text of every email message, and analyzing it, we got a world where you could use email and largely be free of spam. But it did come at a great privacy cost; the same access that allows ML to categorize your email allows anyone to read your email; server administrators, hackers, law enforcement.
I'd just like to offer a counterpoint here. I've been running an email server for myself and some friends for more than five years now and I've been surprised with the low amount of spam we were getting.
Two of the users eventually got caught in a more obnoxious torrent of spam so I configured rspamd. It uses a variety of techniques, including a Bayesian filter score, blackhole lists and greylisting. It resolved all spam issues with zero false positives. Either our spam is an extreme outlier (it doesn't look like it) or filtering spam doesn't require as much ML we're led to believe.
Back in the old days if the Internet, there was no cryptocurrency. I strongly believe (crypto)payments can be used as a pretty effective anti-spam measure in the future.
Don't all platforms with added messaging make this mistake at a certain size? Well done to keybase I suppose. I'm sure I read about github having the same exploit years ago, anyone could add you to a repository and it would just show up on your profile.
As a Keybase user for a number of years I'm very happy with the platform. I'm probably part of the silent majority who use Keybase and have been genuinely happy with it and don't speak up when others have complaints. I use it for personal messaging and for my business and it has been great.
I think Keybase's position on this is on point. This is spam and needs to be dealt with as such. It's no more an issue than with email. Anyone can send you a virus or harassing message in your email, but where is the angry mob of people beating down the doors of every email provider?
There is certainly a problem that needs to be addressed, but lets not blow this up into something it is not. Keybase's spam controls will continue to mature as it grows.
I deal with email spam by dumping all emails from non-whitelisted addresses in the spam folder. My phone has an app to auto reject calls and texts from non-whitelisted numbers. If somebody wants to contact me, they can damned well get my consent first. If they can't be bothered to do that, then they have nothing of value to say to me.
Is there any reason you chose Keybase over other solutions? From my perspective, it's like Wire but without the video calling or end to end encryption, or like WhatsApp but without the network effect, or like Slack but without a number of features. I don't really understand Keybase's selling point.
There is no video calling, but I already have other solutions that I use for that. Keybase is end-to-end encrypted as mentioned in the other comment, has good multi-platform support, and is free. The fact that the user can revoke a device if it is compromised is excellent. I also have intentions for using it as a secure SSO ID across company applications using the API(https://keybase.io/docs/api/1.0/intro). (Basically replacing how some companies use Active Directory)
For me the secure identity and communication part of Keybase is a critical base layer that no one else really gets right. I can have a new hire create a Keybase account and use that to securely exchange documents (e.g. w-4 allocation, health insurance, etc.) two weeks before they are even part of the company.
The only long-term downside to Keybase for me is it is a centralized cloud service run by a single company and the application is not open source. What I really want is a decentralized open source version of Keybase that's operated as a global network that lots of companies/individuals ran nodes for and you paid for your use of the network. That way I'd be more certain that it will be around in 10 years time.
Regarding "Keybase is end to end encrypted", it's sorta true but comes with an asterisk. I answered the sibling comment who asks that question directly: https://news.ycombinator.com/item?id=21741466
It's a relatively minor issue though (and one they could fix at any moment, it's not a crypto flaw but a verification flaw), so it's probably fine to send sensitive data over it. Definitely better than what most people use :)
> like Wire but without the video calling or end to end encryption
I'm not quite sure what you mean here, but Keybase does have end to end encryption—I think they're trying to position themselves as "Slack with end-to-end encryption."
The app is only end to end encrypted if you trust the server to give you the right keys from the beginning (it's E2EE meets TOFU): since there is no way to verify what information (the "sigchains") the server sent to your device (no safety number like in signal, encryption key like in Telegram, fingerprint like in Wire, or whatever you call it), you have to trust the server. The app does verify that nothing changes, so the server has to consistently lie to the device, and to app clients only because a command line client could verify the keys. Then again, since very, very few people do or can do this verification, and since the verification tutorial in the documentation is relatively complex and broken (an api call doesn't return a signatures field the tutorial relies on) and nobody seems to have noticed, it's probably a safe bet for an attacker that compromised the server to just MITM all devices of some users without being noticed.
Note that the blockchain magic does nothing because the app doesn't verify it, and if it did, it would have to be a normal bitcoin client, which would take lots of traffic, storage (even with SPV, you need all the block headers), and shifts the trust to a lot of third parties instead of one (so that's quite trustworthy and great for my grandma that doesn't verify keys, but personally I'd prefer to just check a key in favor of running a bitcoin client on my phone). But that's not implemented yet so this point is moot anyway. And if I'm not mistaken, one needs to compute the merkle tree completely, that is, hash all sigchain of all Keybase users (imagine they become popular and you have to download a literal billion sigchains and hash them all together on a phone) to match it against the final value you get from the blockchain.
Finally, someone brought up verifying keys with another device. I'm not sure if that works. It might, depending on how the key exchange works and if it forces you to verify something in the app. If you don't, I mean, in the situation that the server spoofs your sigchain (MITM) to your friends, it can do that between your devices as well and report whatever value it used for the merkle tree to your command line client so everything checks out.
So it's not completely broken, but trusting the server on first use is m a lesser guarantee than all other E2EE software, and the fix is really simple so I don't get why they don't implement it (note that I don't mean to hint that they're indeed MITMing and that's why they don't let people verify it; I genuinely don't understand why not allow people to do this, I see no reason). My best guess is that they either didn't think of the scenario themselves (and NCC also missed it, which makes sense since they verified the crypto and code and not how a normal user would actually verify this in the UI) or they don't want to admit now that it depended on closed source servers being trusted all along.
Sorry, but doesn't the client check the published keys itself? According to this document the client verifies the key that has been published on twitter or wherever else the user you are interacting with has publicly confirmed his/her identity. https://keybase.io/docs/server_security/following
My understanding is in the event of a server compromise in the beginning then the fake public key for the user that the malicious server would be sending would be easily detectable due to this client side check that is occurring. Whoever is behind the MITM attack would also have to compromise Twitter and all other places the user you are chatting with has published, no?
I didn't connect my account to Twitter or HN or anything, I just have a Keybase account to chat with a friend and wanted to check whether it's secure.
I guess this could work though, from the app I can indeed configure third party accounts (I guess in some next step, it'll tell me what to tweet to prove it). Assuming my phone generates the proof locally, that would prove it without doing manual verification, unless both Keybase and Twitter collude to attack us (or an attacker compromised both or sent NSLs to both), so that seems extremely unlikely.
Does the Keybase client check this by itself though? It seems a bit odd, the app connecting to third parties, but it could be. Like, I'd find out your IP address by adding a website proof where I host a text file.
We can test this if you want? Then I'll pcap my phone and see, while adding you, if my client connects to whatever third party you have configured.
Yes, supposedly the client scrapes it using the website. They have a number of third party integrations they do this for. It's actually a point of contention for them to add more third parties within the community. (People wanted LinkedIn and various other services) Going forward they want it to be the other way around and have third parties to start integrating with Keybase. (https://keybase.io/docs/proof_integration_guide)
I ran the test. What I did was run `tcpdump -i wlan0 -w /tmp/pcap` on my phone as root. I deliberately waited searching your username in the Keybase app until after starting the packet capture, so it couldn't have fetched your keys already. I also didn't add anyone else for at least a few weeks. After starting the capture, I searched your username, hit connect, and stopped the capture only once it was done connecting and it proudly claimed that this chat is end to end encrypted (this took a few seconds).
I looked at two things: DNS results in case there is a quick win (like a lookup for Twitter) using `tshark -e dns.qry.name -Tfields -r /tmp/pcap | sort -u`, and when there was no Twitter lookup to be found, I looked into IP traffic using `tshark -r /tmp/pcap -e ip.dst -e ip.src -Tfields | tr \\t \\n | sort -u`.
None of the IP addresses belong to Twitter in terms of reverse lookup or whois info. Since api.twitter.com (like *.twitter.com, as far as I can find) is hosted in its own IP range, that pretty much concludes the test already, but I dug into each IP address just in case they use some endpoint I don't know about.
The only IP which it talked to in the right time window and I couldn't attribute to a particular app was 52.216.100.45, which (SNI tells me) is AWS S3. Does Twitter uses AWS S3 and does Keybase connect to that directly without going through api.twitter.com? Seems strange.
The other IP addresses my phone talked to in the right time window are either pre-established connections (it would have to keep a permanent connection open to Twitter, and since I didn't add anyone for a while, that would mean it keeps a connection to Twitter open whenever I open the app... I would say we can rule that out) or attributable to other apps like Spotify (I am indeed playing music).
TL;DR it doesn't seem to check your Twitter proof.
It looks like Keybase is using mobile.twitter.com. I just ran `sudo tcpdump -x host mobile.twitter.com` while browsing to ahnick's profile in the Keybase app on my Mac, and got a flurry of activity. It doesn't seem to do that if I just start a chat, however—it only happens if I pull up his profile (i.e. the screen that lists his Twitter account).
I confirmed that the keybase desktop client also seems to be using mobile.twitter.com when I was scanning with wireshark. I know it is executing when going to the profile and it may be executing certain times a chat is initiated, but I'm unable to locate in the code base where this is occurring for chat. For the profile the code location for the client desktop appears to be here -> https://github.com/keybase/client/blob/master/shared/actions...
I guess it's good to know that it checks it in response to random actions, even if not when establishing a self-proclaimed end to end encrypted chat :P
Btw mobile.twitter.com is also hosted in their own range (104.244.40.0/21), so I would have spotted that if it had been contacted when I tested it.
I don't know why it seems odd to you, it is literally what Keybase has been about since its start: the point is that you can bootstrap trust by linking to multiple already known identities (like twitter, hn, github) in a secure way. Even if you dislike all the other things Keybase has done since, this is a significant improvement over web-of-trust or TOFU.
It should be trivially verifiable by yourself: just watch what requests your device is making. And the app itself is open source, so you should be able to trust it.
Edit: this comment can be ignored since it doesn't seem to verify third party proofs in the first place. As far as I can tell, it just queries the Keybase servers and calls it a day, so the trust anchor is still only Keybase unless I overlooked something. More details in my other comment: https://news.ycombinator.com/item?id=21748454
---
> It should be trivially verifiable by yourself
Yeah sure, once you realize that third parties are required for security.
This shifts the root of trust from just Keybase to Keybase + a third party. That's not quite what I would call end to end encryption, at least not if there is no fallback to checking the keys manually. That's just not what the word means to me, even if the risk is sufficiently low that I guess it can be considered equivalent.
So I'm not saying it's a bad thing. If indeed all chat apps had such a scheme where third parties vet the keys, i.e. if it were commonplace to have to compromise two or more companies' servers before you can MITM someone successfully, it would be a huge improvement over the current state. Keybase is definitely being innovative here. It's just not how it's marketed (namely as being a secure chat in and of itself), and I hadn't realized that this might be what they mean when they write "end to end encrypted [but only if you sign up with a trusted third party!]".
IIRC a PGP key is one of the “third parties” you can attach to your account, so assuming that the app checks those, you could get verifiable E2E that way. I’m also quite surprised by your findings about Keybase not checking verifications—my impression from their marketing/docs was that they made a point of doing that. I’m not in front of a computer right now, but will look more into it later.
> The onslaught of sexual harassment on platforms like early Twitter (and later twitter for people of notability), @KeybaseIO, every naive social network is an attack on the right to exist in public. It is the inverse of a privacy problem.
> But the conceiving of this as a privacy problem brings the wrong solutions. It means we are offered tools to remove ourselves from public view, to restrict our public personas, to retreat from public life. It means women are again confined to private sphere, denied civic life.
> But the conceiving of this as a privacy problem brings the wrong solutions. It means we are offered tools to remove ourselves from public view, to restrict our public personas, to retreat from public life. It means women are again confined to private sphere, denied civic life.
Yes, welcome to real life.
Where I can't say I'm an atheist back home because I will get beheaded. Or say what I think of capital accumulation in SF because I will never work again.
And if you take the cowards way out of "We should only protect people for what they are and not what they do", being a woman in this day and age is a choice on par with being blond or a socialist.
> Where I can't say I'm an atheist back home because I will get beheaded. Or say what I think of capital accumulation in SF because I will never work again.
These are bad things, right? Like you want to live in a society where this doesn't happen, I assume? Or are you saying this is all right and proper?
I want to live in a society where I can live my life as I see fit in private with as little performance art in public as possible.
The idea that your public persona should be anything like your private one is so wrong its laughable.
Right now SF is giving most of the middle east a run for it's money for the number of things no one believes but pretends to so they aren't killed - or worse become unemployable and homeless.
Yes, but I hope you'd agree that if a woman says, say, "I'd enjoy going to the local tabletop game store more if people didn't always hit on me there," the response of "Why don't you stay at home and close your door so you can have safety and privacy" is a little bit missing the point.
Not denying this happens on the internet but it seems like these people weren't aware that the crypto currency incentive on keybase was creating this kind of spam for everyone and not specifically them.
It's a different kind of spam. These women weren't receiving scammy cryptocurrency messages, they were (are) receiving "hey beautiful" catcall-esque messages.
It obviously is partially a function of popularity, but this happens on basically every platform that doesn't provide effective countermeasures. (Ask your female friends whether they've ever gotten unwanted messages on Instagram or Facebook!)
The broader point is that if Keybase had listened to its female users and implemented anti-harassment tools in the first place, it might not have ever gotten to the point where cryptocurrency spam was endemic on their service.
Yeah, it's interesting. The specific thing that seems to have happened is that Keybase attracted a certain user base to their platform by offering a cryptocurrency drop, and also, that user base seems to have the idea that every messaging app that has women on it is a dating app. The catcalls weren't there in this number before the cryptocurrency drop - but also the messages are "ay bby" and not "plz send your stellars".
The client is here, right? https://github.com/keybase/client
I'd prefer to see "discuss on a GitHub issue" or "open a pull request" to "send +1s to these email addresses". (The author does discuss how annoying it is to receive unsolicited messages, after all).
I'd think "contacting is as frictionless as email or phonecalls" sounds reasonable for messaging. (EDIT:although email avoids 'unsolicited messages' with spam control, phones with "phone number is secret"; so perhaps not). Another suggestion: Maybe UI would help this; on FB messenger I can't see messages from strangers unless I go into the "messages from strangers" tab. That seems like it'd solve annoyances from unsolicited messages.
Frictionless phone calls worked for decades until automation made telemarketing possible, at which point we had laws that stemmed the tide for a bit, and then further automation made anonymous telemarketing / scamming possible, and we're on the edge of a cultural shift to not picking up the phone when you don't recognize the caller. The latest version of iOS already has a checkbox to block all calls from people not in your address book (24/7, this is a separate feature from "Do not disturb").
Frictionless email had this problem since the very early days. A huge amount of algorithmic effort goes into identifying spam, and there are still large numbers of false negatives and false positives.
These were architectural mistakes, and it's not a credit to a new messaging platform that it doesn't see this as a problem worth solving from day 1.
> The latest version of iOS already has a checkbox to block all calls from people not in your address book (24/7, this is a separate feature from "Do not disturb").
Thank you! I have been wanting exactly this for a long time now -- my phone is pretty much always on DnD for this reason. I guess I'll finally upgrade to 13 now.
I think the author got it right. Yes, those other platforms allow anyone to message you, but they don’t consider those features anymore. The way we are trying to mitigate is spam filters everywhere. Spam is a much harder problem. It’s far simpler to have a double opt in.
I'm not sure this counts as a privacy problem. Freedom from harassment is important, but it does not fall under privacy. I'd even say that it is more important than privacy. Privacy is about what others can learn about you, not what they can do to you.
Yeah... spam sucks and Keybase should probably shunt unfollowed messages into a second screen or do something like Instagram where the first message comes with a "do you want this person to be able to message you?" prompt where you can easily block them, but there's no private information being leaked here.
Indeed, it's intended functionality that you can talk to anyone and spammers are apparently just discovering the platform, and Keybase is reacting to it (see the recent blog post mentioned in other comments). The article is written a bit confusingly.
I used to love keybase and used it for a while, but somehow since the crypto coins donations I started getting followed by random people and getting some "spam". So nowadays I avoid it and stick to Signal. I really like the idea behind it though and I hope they manage to solve of these issues eventually!
The spam folder in my Fastmail account usually got only one or two spam mails in a month but recently it went up to ~10 per day. The only change that happened around the same time was that Keybase added some crypto-play money to my account which is associated to that Fastmail account.
I know that correlation does not imply causation but this stellar addition after the fact left a sour taste in my mouth. :(
Is that supposed to make it better? "It's okay they don't take things seriously, they make a practice of not treating things seriously, so you should use their service?"
(And, like, I get it, I have a good knack for being a troll and annoying all my friends, but at least I'm aware that this isn't a good thing and if I were running a business, I'd find someone else who could keep my instincts in check!)
Suddenly I'm less confident in Stellar. wonder if this is really helping the foundation if Keybase is being this unprofessional in public communication.
> A solution like "you have to opt into being added to a team" is really ugly from a UX perspective and harms the service for honest people. We have thought tons of this.
Clearly, this person has never been involuntarily added to a chatty group MMS conversation.
> All of a sudden, I started receiving lots of random messages from people without profile pictures.
> These were people I didn’t know contacting me on a pretty frequent basis, and I had no way to opt-in to their messages. Pretty ironic for a platform built on privacy.
> I wasn’t the only one. After asking around, it seems that everyone I knew on Keybase was getting these. But of course, women with female names and profile pictures got a lot more than most men I knew. Other women online were experiencing it, too.
One of the companies I do contract work for uses Keybase to share credentials between engineers. Like database credentials, AWS access keys, ect. Including production credentials. I felt like it was a security risk when they started sharing creds with me over Keybase but didn't know enough about Keybase at the time to feel comfortable saying something so just followed their process.
Does anyone here use Keybase for this use case? Is it secure?
I've used it for this use case. When I onboard new employees, I add them on Keybase and have them add me, and then I send them their AWS keys via Keybase chat.
I've also used it to exchange AWS keys and other credentials when consulting.
I chose keybase because it was the easiest chat to set up with end-to-end encryption that works on the desktop, where I generally needed to be to copy/paste the keys.
It's certainly not the most secure way to share keys, but it's fairly secure and a decent trade off since I consider the credentials I'm sharing on there to be medium value at most.
It depends. If you use the official app, then it's sort-of end to end encryption but with an asterisk that you have to trust their servers not to mess with you from the beginning. They can't start intercepting at will, though, they have to target you from the beginning, and if the server did that with everyone, odds are that someone caught on by now. So it's probably fine.
If you use a client where you can view the crypto keys for out of band verification (I think the command line client can do this, but it's awful to use as daily driver), then it is actually end to end encrypted, and you should only have to do this once.
Verifying your key in the command line client and then using the app will not do, since the server can selectively lie to your app. I'm not saying it's likely, but when speaking of sending keys to the kingdom through it, it can be a reasonable precaution to verify crypto keys for the client you're using, depending on your company and threat model (if you're in the USA, well, so is Keybase so that's less of an issue than when you're in Iran and you think Keybase is magically end to end encrypted with no verification needed, as their docs suggest). Since all devices connected to your account receive a copy of the data, it doesn't matter which device you use to send or receive the secret keys.
Yes, and yes it is secure. That is to say the data is encrypted and only you and the person(s) you are sending to have access to it.
I have used it for credential sharing and use kbfs (Keybase's encrypted file sharing) for a simple secret storage mechanism for shell scripts. I map my encpass (https://github.com/plyint/encpass.sh) directory to kbfs.
The issue described in this post is the same issue that drove me to stop using IRC and XMPP.
I’m all for open protocols and interop, but I’ve had an online stalker since dialup (Winsock). Building a system where anyone can message anyone is the same problem in each system.
Anti-spam is not the solution. Harassment (and spear phishing) issues will not be solved by anti-spam.
Have you tried Signal? Not as majy features as Telegram, bit they have very good reasons for why the missing features are difficult to do and are working hard at solving the crypto problems necessary.
Discord has a similar problem where crypto scammers come on any public servers and mass message all the users. There are no controls except to block them after the fact one by one.
No such issues on the latest stable Firefox on Linux here.
The background is one of those that looks like it might cause issues while scrolling with a lot of monitors though, are you sure it's the site / some software and not your hardware?
(I had to use the pro offering, at https://pro.coinbase.com/, as apparently Stellar isn't available in the main app for US users yet, but it worked fine.)
https://keybase.io/blog/dealing-with-spam