Don't forget Tor Browser https://www.torproject.org: the Tor Project modified version of Firefox. It aims to make all users look the same, making it difficult for you to be fingerprinted based on your browser and device information.
Mullvad Browser https://mullvad.net/en/browser: developed in collaboration between Mullvad VPN and the Tor Project, based on Tor Browser but meant to be used with a VPN instead of the Tor network.
I don't want ads all over my screen when I browse the web. It doesn't mean I don't want to pay for content (I do pay). If ads were all blocked, websites would charge for content, and I believe people would pay. I would. I'm glad to pay for a better quality of life and less consumerism. Meanwhile I use NewPipe and uBlock Origin which I believe have a good impact on this society.
I for one do not because I do not have a Google account, and do not want one, because I do not consent to their data harvesting practices or give money to surveillance capitalism corporations.
When I can pay creators directly with anonymous microtransactions, I will.
Clicking a link to open a chatroom directly, with no account creation process, is infinitely simpler than account creation, potentially with several layers of verification (CAPTCHA, email, phone verification to join a server...).
This. You just To: the mailing-list and depending on the project CC: the maintainers.
No subscribing needed. Standard policy on all mailing lists is to reply-to-all so you'll get always CC'ed on replies. This also makes it very easy to pull in more people into a discussion, even across different projects.
Many mailing lists today reject posts from non-subscribers.
Of those that allow posts from non-subscribers, you will find that many are configured such that you will not get a reply, due to "reply-to munging". Your message will go to the list, but with a Reply-to: header designating that list, instead of (or in addition to) setting the more modern mailing-list-related headers.
Reply-to-all isn't a list policy; it's a behavior of the individuals. Some people don't reply to all. They think they are, but only the post author gets their reply. That is one of the motivations behind the Reply-to.
The CC part is highly conflicted. Most maintainers hate double emails, whilst some loudly insist to be CC'd, esp. the Linux kernel folks. So you need to read beforehand the preferred etiquette.
And nevertheless, the tone on mailinglists is entirely different (and mostly extremely childish and unprofessional) than on ticket trackers.
You don't need to subscribe. You are in CC when people want you to be notified, otherwise there are web interfaces you can browse. See https://lists.gnu.org/archive/html/guix-devel/ for example. On each message there is a button: "reply via email to [...]".
I usually know, when the interface is not too shiny, that the content might be good. It's the same with HN. And those interfaces are still very easy to understand and use.
That being said, there is certainly room for improvement.
There's something to this idea, I think. The less polished a tool is, the more I'm inclined to think it was built by the community for community use. There's so much talk about enshitification, and I'm struggling to recall when a tool with a less-than-polished interface had that problem.
The example that springs to mind is spamgourmet, which has a FAQ about why they don't redesign their site. I've used the service for about 20 years, and while there is a bit of a gatekeeping vibe to it, there is also a good reason: they have very few resources for support, and want to attract a certain crowd to minimize the support burden. It seems it's been working for a couple of decades, at least.
> Q. Couldn't you make the whole thing a lot easier to understand by redesigning your site and providing instructions in a more clear way?
> A. Probably. Frankly, we're trying to build a user base of people like you, who probably have some familiarity with the way email works and who are willing to read FAQ's. This is to keep our support burden to a minimum (this is a non-commercial service). So far, the approach has worked well -- just about all our users hit the ground running with no need for support, and it's our belief that those users who would require support generally don't sign up in the first place, perhaps because of the geeky presentation of the site. That's not to say we don't provide support where it's needed -- after skimming this FAQ, please don't hesitate to write if you have a question or believe there's a bug.
I tend to actively seek out projects like this, since I don't mind the blow to usability, and very much appreciate that they provide the service and don't pepper me with annoucements about their new improvements or their changes to their pricing structure.
You left out the entire configure SMTP step. Honestly I’m not even sure how to do that if your SMTP server requires 2FA and does not allow legacy app specific passwords.
That uses app specific passwords, and with Google Workspace, the administrator can completely turn off these “less secure apps”. Pretty sure Office 365 has the same.
Sadly you’re right. Microsoft has brainwashed many IT departments into forcing oauth on everything, no app specific passwords, no regular passwords, nothing else. Thankfully they do support this on imap and smtp, but you have to have something that can handle it. I use a modified version of isync with the sasl plugin to fetch mail, and a python smtp sender that supports the oauth flow along with a set of scripts for generating a new refresh token every few months. It’s a heck of a lot of stuff to maintain, but at least it works. If anyone’s interested I could provide links or upload the modified versions to fix o365 quirks.
Multiple enterprise customers use my software (https://emailengine.app) because it can proxy OAuth2-enabled IMAP/SMTP connections as regular password-based sessions. Turns out there are a lot of legacy, like all kinds of cron scripts, that want to connect to some IMAP account to check and do something. It all breaks down once the organisation enforces OAuth for their email. So, personally, I don't like it at all, but as a software developer, I'm really happy about it. Helps with my sales effort :P
Oh that’s pretty cool, thanks for the link. I’ve used davmail as a proxy like this, just for the oauth support, but it doesn’t scale to large mailboxes or high traffic well at all. May forward this along for some of our internal services people.
There’s another method that doesn’t use app specific passwords but I’m not entirely sure how it DOES work - it opens a connection and then gives you a web address to go to in your browser to authenticate with 2fa. And then somehow it magically works until it decides it doesn’t like you anymore.
I never studied the protocol of Gmail/Exchange/etc. 2FA, but I suppose the SMTP auth token expires after a while, and the client somehow hasn't implemented token refresh? Anyway, glad to know there is a way (?) to get git-send-email working with stricter 2FA.
I've always assumed that the server side stores as much information about the client as it can, so not just "username/password" but source IP, client headers, etc and somehow uses that as a "session token".
Every mail server/provider that provides 2FA that I used allows for configuring "tokens" (called a bit different everywhere) which are a high entropy random string, and some of them require TFA only for IMAP or POP, i.e., getting mail, not SMTP, i.e., sending mail.
If you use this proxy of mine then any IMAP (or POP/SMTP) client can be used with a “modern” email provider, regardless of whether it supports OAuth 2.0 natively: https://github.com/simonrob/email-oauth2-proxy. No need for your client to know about OAuth at all.
If your system cannot relay mail correctly already, as most office setups are easy to configure to be able to provide that without extra config, at least for Linux setups, then the set up means having something like the following in their gitconfig:
FWIW, I haven't done that kind of setup for years because modern iOS/macOS does email server discovery, where you enter "bob@example.com" and then it does discovery and figures out the right imap.example.com:587 etc for you by looking at DNS.
Yes, such things are nice. The well-known URI [0] system is also sometimes used for this, at least there's one entry for Thunderbird under the "autoconfig/mail" subdirectory. Having some of those auto-config methods available for git send-mail could be nice, as it would lower the barrier a bit further, even if most devs are probably able to check their SMTP endpoint and port.
Mullvad Browser https://mullvad.net/en/browser: developed in collaboration between Mullvad VPN and the Tor Project, based on Tor Browser but meant to be used with a VPN instead of the Tor network.