Threads for gbr
-
Pet peeve - this
personutility saying that GMT and UTC are the same. They are not.Edit author seems to know the difference, OpenSSL X509 does not.
-
-
-
-
-
In my experience that is true everywhere.
When someone say whatever time GMT, EST, CST, PST, MST.. they always mean whatever that time happen where “i” am and the person on the other side need to figure out what time it actually is..
This coming from someone that work with support globally (mostly Europe and America continents tough) and has to deal with this on a daily basis, basically i need to track regular\daylight almost everywhere to try figure out when my meetings are..
-
-
This is my experience as well and it is frustrating. I always write ET, CT, MT, and PT for the main US timezones. It’s viewer letters. Why do folks stick the S in there? Nobody seems to ever stick the D in there!
-
-
-
-
-
-
also, “i don’t care that these extensions can read and change all your data on websites you visit”
-
the argument that Rust prevents the “goto fail” ( https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug ) is .. weak.
the thing that prevents it is an unreachable-code-warning, and that is available for the C language too (even the linked wikipedia article mentions this)
-
IMHO it’s a very solid argument. Rust prevents it on many levels, much deeper than a lint:
- Rust’s
ifalways requires{}. The 2-line form ofifthat causedgoto faildoesn’t exist in Rust. - Rust doesn’t pass values through
=, so theif (err = call())form doesn’t exist in Rust either. - Rust doesn’t have
goto. Rust’s automaticDropmakes thegotocleanup pattern unnecessary. - Rust uses
Result/?for error handling. It’s rare to need anerrmutable variable.
The code quoted on that Wiki page in Rust is:
hashCtx.update(&serverRandom)?; hashCtx.update(&signedParams)?; let hashOut = hashCtx.finalize()?; - Rust’s
-
-
-
doug-moen
1 year ago
|
link
| on:
Google Is Testing Its Controversial New Ad Targeting Tech in Millions of Browsers. Here’s What We Know
Here’s what I’m doing to adjust to the new era of dystopian surveillance capitalism:
- Replaced my old MacBook Air with a Thinkpad T14 running Linux (currently Fedora, which has less spyware and advertising than Ubuntu)
- Firefox + UBlock Origin is my primary web browser. Configured so it mostly doesn’t “phone home” to Mozilla.
- Ungoogled Chromium (from the flatpak store at flatpak.org) is my backup browser, for web sites where Firefox has issues. Guaranteed never to phone home to Google.
-
I’m interested in why you installed “ungoogled chromium” from the flatpack store?
I personally install it from RPM fusion. (Which you might wanna install if you want to watch any video/listen to any music on fedora)
$ sudo dnf info chromium-browser-privacy Installed Packages Name : chromium-browser-privacy Version : 88.0.4324.150 […] Source : chromium-browser-privacy-88.0.4324.150-1.fc33.src.rpm Repository : @System From repo : rpmfusion-free-updates Summary : Chromium, sans integration with Google URL : https://github.com/Eloston/ungoogled-chromium License : BSD and LGPLv2+ and ASL 2.0 and IJG and MIT and GPLv2+ and ISC : and OpenSSL and (MPLv1.1 or GPLv2 or LGPLv2) Description : chromium-browser-privacy is a distribution of ungoogled-chromium. […]-
-
What kind of sandboxing does the flatpak-ed package get you? It’s a useful point to remember – a while back (I’m not on Linux anymore so I don’t have a more recent data point) a lot of applications from flathub were packaged without much sandboxing at all, e.g. they still had full access to the user’s home folder.
-
Fedora has an “app store” GUI called Software. It is far more user friendly than using the “dnf” command in bash, at least if you are coming from MacOS. On my laptop, since I installed it, UnGoogled Chromium shows up as an installed application in Software, together with a lot of useful information, including an indication that it is sandboxed, with the following permissions: Network, Devices, Home Folder, Legacy Display System.
-
Oh, thanks! I couldn’t find an explanation of what the “friendly” names mean but assuming the most obvious mapping to Flatpak permissions (here) I think it would go something like this:
- Home Folder means it has unrestricted access to the home folder (which is slightly better than
--filesystem=hostbut, as XKCD famously put it, not that good…) - Devices means it has unrestricted access to things like webcams
- I’ve no idea what Legacy Display System maps to – presumably either
--socket=x11or--socket=fallback-x11? - Network is obvious, I guess :-)
This is actually a little better than I expected, I think?
- Home Folder means it has unrestricted access to the home folder (which is slightly better than
-
-
This page is a little clickbait-y but still somewhat true: https://flatkill.org/2020/
Long story short, yes isolation is still an issue on flatpak
-
-
-
-
-
MacOS has telemetry that cannot be disabled. You cannot modify the System folder. Apple wants to be an intermediary in everything you do, they want to see all your data. You are encouraged to store your data on the Apple cloud, which is not end-to-end encrypted, so that they can hand your data over to the government without your knowledge(*). You are encouraged to download apps from Apple’s app store, and even if you don’t, MacOS phones home about apps not installed from the store. I don’t want to use these services, but the UI has built in advertising for these unwanted services that I can’t disable.
Apple has been very successful at branding themselves as pro privacy. A lot of people believe their bullshit. Here’s an experiment that you can try. Go to an apple store and buy something using cash (so that Apple doesn’t know your identity). When they ask for your email address, refuse to give it to them. See how that goes for you. My experience is that they try to inflict as much pain as possible, but with negotiations, it is possible to leave the store with your merchandise and a receipt. But it is not easy. I try to use cash for everything (although I’ve made exceptions during the pandemic), and the apple store has by far the worst experience.
We live in an age of anxiety, where there is an ever increasing number of things that you are supposed to be anxious about. The pandemic, of course, but now that we are getting vaccinated, instead of that being a reason to be less anxious, you are now supposed to be anxious about getting and protecting your vaccine passport, without which you will be denied access to services. And of course we are supposed to be anxious about surveillance capitalism. This all sucks. I want to minimize the number of things in my life that generate anxiety: deal with the problem once, then stop thinking about it. The rational thing is to get rid of all my computers and phones, and unplug from the internet. I’m not ready for that yet, so I’m replacing my gear with new gear that doesn’t surveil me. Hopefully that will allow me to stop thinking about those particular issues.
-
-
I recently got sent a mac by my employer for compliance reasons, and the process of setting it up was quite a trip. I felt like I spent twenty minutes answering “no” to various forms of “OK but can we collect this piece of personal information? How about if we phrase it slightly differently?” before I could even use the machine at all.
In the end they refused to take no for an answer re: my mobile phone number, and after an experience like that I don’t actually have much confidence that they take my consent very seriously for the other pieces of information that I did not agree to.
Luckily in my case the compliance concerns can be addressed by simply doing my development inside a virtualbox VM running on that machine over SSH.
-
-
You are encouraged to store your data on the Apple cloud[…] You are encouraged to download apps from Apple’s app store, […] Apple has been very successful at branding themselves as pro privacy. A lot of people believe their bullshit.
Also, you are encouraged to buy into the non-Mac hardware ecosystem (iPhone, Watch, etc.) with their own app store “soft” lock-in (using Things/OmniFocus on Mac? Why not buy the iPhone version!?).
Technically, one can use a Mac and avoid the rest of Apple’s ecosystem (by running Chrome, Thunderbird, open source apps, etc.) - but most people will eventually get sucked into Apple’s marketing vortex. I know because I did; which is why I avoid touching anything Apple with a ten foot pole.
-
-
if you don’t like the telemetry done by MacOS, that’s totally fine, but there is no need for the hyperboles, like “they try to inflict as much pain as possible”. them knowing your email address is better for their business. of course, it is worse for your privacy. but it’s just a business decision that you can dislike, not them trying to inflict you pain like some james bond villain with a lake with sharks :-)
also, in general, you will have to trust the company that makes your operating system. not because they are trustworthy, but because if they were evil, they could just read everything you do on your computer and you would never know. so simply pick one that you can trust the most. (and it applies to linux distros too. i don’t think anyone is reading and understanding every fedora patch).
-
not them trying to inflict you pain like some james bond villain with a lake with sharks
It’s a figure of speech
you will have to trust the company that makes your operating system
A company doesn’t make my operating system, but even if one did it’s open source, which MacOS is not
-
-
james bond villain
I think this reasoning is problematic and completely ignores wolves in sheep’s clothing. How many James bond villains have ever really existed ? We agree that sharks exist but what about the following
- The nigerian prince scammers don’t really say hey want your money for personal benefit, but dress up the message in the language of victimhood.
- Sexual predators feign weakness, especially if they are older men before making the victim unconscious.
- Pedophiles work in charities or armed forces but present themselves as pillars of community.
- Religious people commit evil on completely innocent people but dress it up in the language of love, justice and purity. You don’t think of nuns who steal babies as human traffickers.
- Communists preach egalitarianism but practice slavery under the guise of enemies of egalitarianism.
- Pharma companies preach healing but sell addictions.
- Under the guise of freedom of speech, pornographers exploit people from towns.
- Shell and coca cola are exemplars of making the world a better place.
The list goes on and on. Almost every idea which seems innocent enough is abused by wolves in sheep’s clothing and not james bond antagonists. Maybe there is no such thing as sheep and we are all wolves. Heck even the open source contributors are abused under the guise of openness and community, while the parent company seeks funding.
Social media companies, including Google, claim they are making the world a better and connected place while allowing sexualisation of pre-teens and enabling predators on their platforms. They are selling private user data, allow non-state actors to influence elections, let unverified stories to run amok, abuse copyright protections and run behavioral experiments on users. How difficult is it to enable age verification ? You can always store sha(government-id) or use credit cards to verify age.
We merely have to ask the question are Google and Apple, wolves in sheep’s clothing ? The answer is obviously yes. Apple is a tobacco company. In what ways can they be stopped ? I don’t think limited liability is the answer.
-
It’d probably be a good idea to strip out some of the more, um, controversial items from your comment to avoid a hellthread here litigating offtopic matters.
-
-
We live in an age of anxiety, where there is an ever increasing number of things that you are supposed to be anxious about.
No offense, and I honestly mean that, but it feels as though you’ve got a little more anxiety going on than most of us. One valid way to deal with anxiety is to accept that some things are just facts of life in the modern world. For example, I use an ad-blocker, I don’t use Chrome, and I choose devices and services that are at least reasonably secure, but I gave up trying to control every piece of data I own because the attempt was causing me much more anxiety than just going with the (admittedly unfortunate) flow.
Just a thought.
-
“Don’t worry, be happy” is not a serious answer to anxiety. If you decide to surrender that’s your choice, but that doesn’t mean people preferring to fight a managed retreat and prevent a total rout are wrong to do so. At a minimum they will preserve their freedom longer than you and possibly even retake ground that you have ceded.
-
-
-
-
-
I chose the T14 AMD w. Ryzen 4750 (8 cores, decent GPU) because I’m doing open source development and 3D graphics (not gaming), and I wanted this much power. Thicker than my old MacBook, but same mass. Easy to disassemble, lots of upgradeable components. The T14s is too thin, cooling system is inadequate for the 4750 CPU (according to notebookcheck): it runs too hot and throttles. Ryzen uses more energy but performance is comparable to an Apple M1 (faster on some benchmarks, slower on others). Fan noise hasn’t bothered me.
According to reviews, T14 has a better keyboard than X1 carbon. X1 carbon has a better trackpad, but this trackpad can be ordered and installed in a T14 (many people on Reddit have done this). The X1 is limited to gen 10 intel + UHD graphics, too slow for my requirements. It maxes out at 16GB soldered RAM (not upgradeable), too small for my future requirements. Probably too thin to support the Ryzen 4750 with adequate cooling. The display options are better than the T14 AMD, that’s my one regret.
-
I replaced my MacBook Air M1 by a T14 AMD a few months ago and like it very much as well!
Fan noise hasn’t bothered me.
Me neither. The fan is not very loud, definitely much more quiet than Intel MacBooks.
lots of upgradeable components
Love this aspect as well. I added an additional 16GB RAM (for 32GB RAM) and replaced the 512GB NVMe SSD by a 1TB NVMe SSD. There is still room for one more upgrade, since the WWAN slot can be used for some SSDs.
The display options are better than the T14 AMD, that’s my one regret.
Especially in Linux. On Windows the screen is quite acceptable with 150% scaling. Unfortunately, when enabling fractional scaling in GNOME, most X11 applications break (blurry upscaling).
-
Unfortunately, when enabling fractional scaling in GNOME, most X11 applications break (blurry upscaling).
I remember this problem with the X1 Gen3 which couldn’t scale 2x properly, so I could chose between things looking way too tiny or things looking way too large (and very little screen real estate). The 4K screen in the T14s is much better in that regard.
But really the problem is that GTK+ 3 (at least) doesn’t support fractional scaling so things are just a complete mess.
-
But really the problem is that GTK+ 3 (at least) doesn’t support fractional scaling so things are just a complete mess.
For me on Wayland, GTK 3 applications work fine. AFAIK, they are rendered at a larger integer scale and then Mutter (?) downscales to whatever fractional scaling you use. This is pretty much the same approach as macOS uses.
It’s XWayland where it goes wrong, though I think it was with an external screen hooked up, since XWayland does not support mixed DPI.
-
-
-
The AMD variation is near perfect - but there is one downside to anyone, like me, who owns a Thunderbolt device (eg: LG Ultrafine 5k; I cannot go back to non-retina monitors having used this). It has no support for TB3 even with a dock.
-
-
-
The fact that the 4K screen is only available in the T14(s) with Intel is the sole reason I got the Intel T14s (which apparently does not run crazy hot as the Intel T14). Also oddly the T14s can be ordered with 32 GB RAM unlike the X1, so you get a rather similar device with better specs and keyboard and a worse (non-replaceable) touchpad.
-
-
-
the author dislikes that google does not want to accept portability-patches, but i kind of understand. if you accept those patches, now you have to maintain them:
- you need people who understand those architectures
- you need hardware with such architectures to test
- in general, every extra line of code has a cost, because it makes refactoring/reworking/changing the code harder, slows down development
this is extra effort. sometimes it is worth it, and sometimes it is not.
the phrasing in the article like “the Talos user community offered a PowerPC port” sounds like all the extra work is done by not-google, but that’s not how it will be long term.
-
The company that produces the Talos offered Google free CI hardware.
I realise that there would be a non-zero cost to Google, but pardon me if I don’t cry if one of the - if not the - largest company on earth might have to spend a few minutes per release cycle scrolling over a PowerPC block of code.
-
the basic argument of the article is this:
- in javascript, if you have an async function, you cannot call it from a sync-function and get it’s return-value in a sync way.
- in rust this is not true, you can achieve this.
- therefore, rust does not have the coloring-problem.
this might be true, but the more fundamental problem is still there: you should not mix&match sync and async functions too much, otherwise bad things can happen (even the article mentions this). so i think the coloring problem is still there.
this is not something any language (that has both sync and async functions) can escape from i think. for example, async-functions assume they never block (for a long time). so every time you call a sync-function from an async-function, you have to know that it will return shortly.
-
This argument doesn’t even hold up against JavaScript when using Node.js. Although it is a hack and not at all recommended for production use, on Node.js you can use something like deasync to block on promises and other things.
-
if you look at the
postJsonfuncition described in the article as an example of you-might-not-need-jquery. there is no error-handler. how do you find out if there was an error?-
The error handling I do have (for HTTP errors) is in the callback. I don’t have any error handling for network or lower-level errors here. For this use case it’s a somewhat throwaway or easily-repeatable action, and if nothing happens the user can simply click again. Not perfect, but I think reasonable for my use case here.
-
You can set the onerror property to catch network level errors, e.g. https://github.com/Peergos/web-ui/blob/master/vendor/priors/gwt.js#L84
-
-
Memory management is a distraction: Actually, no. I don’t use that many lexical lifetimes and use instead smart pointers. So yes, I have to understand the differences between a Box, an Rc and an Arc, but my productivity is not impacted compared to Node.JS or Go.
then you are simply using reference-counted pointers right? like C++. with the built-in problem that cycles in reference-counted pointers will leak memory, so you have to manually break cycles with weak-references.
-
On the surface it’s similar, but:
-
You can’t have cycles with
Box. -
Rc/Arcmake their content immutable, so if you don’t add interior mutability yourself (viaMutex, etc.) then they are free of cycles too! They’re not always used for shared-mutable state. In async code you often just need to make data safely sendable to a thread that may outlive your scope. -
Content of
Rc/Arccan be safely borrowed, so even if you need them in some places, you can still write a decent chunk of code without touching these types directly. This reduces refcounting overhead and the amount of code that needs to be mindful about cycles.
-
-
-
I haven’t seen very many good arguments against what Moxie has said with regards to competing on features. Comparing this with countries - even in a representative democracy like the United States, our military is a strict hierarchy. This is despite the democratic principles of the country. The reason? There is an evolutionary pressure on militaries to find the most competitive structure - those who have tried other things (as Orwell talks about in revolutionary Catalonia) failed in part due to the structure they adopted. Moxie has noticed the loss of open source projects to these closed companies due to their insistence on a more virtuous structure and has decided that the perfect is the enemy of the good. To me this seems analogous to the arguments between pure utopian anarchists and more pragmatic people (considering Moxie’s political orientation he is probably intimately aware about the tradeoffs here).
-
Since reading Moxie’s polemic against federation (I assume you’re talking about the “Ecosystem is Moving” essay, though Moxie has repeated the idea elsewhere), I’ve slowly come to the understanding that the only way to win this competition on features is to not play at all. After all, there’s almost always someone out there with more money/determination than you, which I guess is especially true in terms of open/community-owned projects vs. more commercial endeavors.
Part of what I’ve come to dislike about these more boxed platforms (to borrow a term from the linked article) is how they’ve made online discussions more ephemeral, both in terms of owning one’s archive, and in terms of being able to stay part of a community regardless of which device/system I happen to be participating from. For most of these platforms, clients running on “legacy” systems (be it older devices or devices on non-mainstream operating systems) are routinely dropped or not developed for in the first place; some platforms place constraints on participating over multiple/alternative devices, such as a mobile device and a desktop device (ostensibly because of E2EE concerns).
This contributes to my nagging feeling that I’m somehow forced, as a user, to keep up with some notion of progress, when all I want is to communicate.
Conversely, platforms such as IRC and XMPP continue to be useful even on ancient or under-powered devices, albeit in a perhaps degraded capacity, and allow for the sort of mixing-and-matching of use-cases made harder by their boxed counterparts. This, to me, is a more user-friendly and inclusive approach to building communication tools; unfortunately, being more inclusive means taking the foot off the pedal, or at least taking a more mindful approach in rolling out features.
-
This contributes to my nagging feeling that I’m somehow forced, as a user, to keep up with some notion of progress, when all I want is to communicate.
Communication (like most human endeavors) is constantly changing. Language changes, communication methods change, speakers change (including marginalized groups into conversations), and expectations around media change. This isn’t “progress” in the Baconian sense but it is change. IRC and XMPP (along with their technical issues which others in this thread have covered in great detail) just hasn’t been able to keep up with changing expectations of communication. Realistically, the general population sends pictures of computer monitors to their friends over Snapchat. Sticking to IRC just codifies a different set of social norms into place.
-
Disagree.
Communication over platforms typically changes because the platforms themselves change. People started sending each other image file attachments instead of image links after image attachments were implemented by popular clients.
Featuritis causes these changes more often than change causes featuritis. Language changes, but those changes can still be represented in plaintext as long as encodable written language exists.
-
Communication over platforms typically changes because the platforms themselves change. People started sending each other image file attachments instead of image links after image attachments were implemented by popular clients.
You’re taking too short of a view of this. Humanity used to send smoke signals and use oral storytelling to communicate. In the meantime, we seem to have invented writing, paper, printing presses, newspapers, telegraphs, radios, and all sorts of other manners of communication. Whenever I see folks say things like change is driven by featuritis, I invite folks to tell me where they draw the line between essential change and featuritis change and to justify why this line is valid.
Language changes, but those changes can still be represented in plaintext as long as encodable written language exists.
Right but what about folks that are hard of sight? Folks that are dyslexic? People that comprehend things through image better than text? Traditionally these folks have been excluded from the conversation. In fact, the history of communication has largely followed the democratization of communication to new actors. Why is plaintext encodable written language the point at which we must draw our line in the sand?
EDIT: I also want to point out that there are people that enjoy change. They enjoy learning new slang, they love participating in new memes, trends, conversations, and ideas. This isn’t to say that new is inherently better, but nor is it to say that new is inherently worse. But there is a contingent of people out there that legitimately enjoy change. If you want to include folks in the conversation (which is the whole point of creating open communication platforms, right, to enable humanity to communicate), you need to account for folks that will change their colored contacts on a whim as much as the person who is fine using their 20 year old laptop to view plain text.
-
Right but what about folks that are hard of sight? Folks that are dyslexic?
Dictation does not require creating a new protocol; that’s a client-side feature.
Why is plaintext encodable written language the point at which we must draw our line in the sand?
Because that’s the minimum requirement for communicating language, and the most accessible form of communication in existence.
there are people that enjoy change
Client-side change is fine as long as that change doesn’t devolve into a boxed platform. Nobody’s stopping you from switching out themes or clients when you feel like it.
-
Dictation does not require creating a new protocol; that’s a client-side feature.
What about sending voice messages? Sending images? Am I not allowed to hear my parents’ voices because of protocol complexity? What about folks that are blind and deaf, or who don’t know a certain language?
Because that’s the minimum requirement for communicating language, and the most accessible form of communication in existence.
Citation needed. We communicated without written language for a very long time. Why do we need to use written language now? How is it the minimum of anything? We don’t even have a universal theory of human semantic processing, so how can we prove that written communication is the minimum?
But why are you so invested in trying to limit my expression? Why must we embrace minima? Because it’s easier for the implementer? Why is the implementer more important than the user? Why is an open protocol more important than the act of communication itself? When I check out a new apartment to rent and I see it doesn’t have central heating, I don’t think to myself “ah of course, what a smart design decision, the builders decided to save on complexity” I think “oh they cut corners and either did not renovate in central heating or they don’t care to support central heating, well, not my sort of place”.
This is the problem that folks bring up when talking about open source adoption. Open source often cares more about principles than usage. FOSS cares more about openness, customizability, and other values that end users care for less than core functionality. If you want to communicate with your fellow FOSS-natives on Freenode and grumble about the kids on TikTok be my guest, but others will not be willing to make that choice. If FOSS actually wants to enable end users and not technical FOSS-natives, then FOSS needs to prioritize users just as much if not more than its principles. In the meantime, others will explore other tradeoffs. Like Moxie with Signal, Element with Matrix, and Gragon with Mastodon. I can tell you that IRC hasn’t changed much and FreeNode hasn’t gone anywhere in the last several decades, yet the mindshare has very much moved away from FreeNode, and that’s because users have put their “money” (or time or effort or whatever) where their mouth is and have voted with their feet.
For me a good metric of success with a communication protocol/product will be when you observe average teenagers in the developed and developing world organically using your product to communicate. They use things like Instagram and WhatsApp but they probably don’t use IRC. I did use IRC when I was a teenager, but there were fewer options then and IRC mirrored the cultural context of online communications at the time much more than IRC does now. I think you’d be hardpressed to get any teenager these days to use IRC.
-
What about sending voice messages? Sending images? Am I not allowed to hear my parents’ voices because of protocol complexity?
Use the right tool for the job. A VOIP protocol would work well for sending voice. You could make a meta-client that combines a VOIP client and an instant-messaging client if you want to do both at the same time. There are better ways to do this than making the protocol more complex.
What about folks that are blind and deaf, or who don’t know a certain language…why do we need to use written language now?
People who are both blind and deaf can use braille readers. Plaintext allows people who are sighted, blind, and/or deaf to interpret language.
But why are you so invested in trying to limit my expression? Why must we embrace minima? Because it’s easier for the implementer?
Yes. I explained my rationale for simplicity in the previous post, Whatsapp and the domestication of users. When complexity grows past a certain point, implementers need to spend more working-hours and need more funds to create a viable implementation; requiring too much funding can encourage dark patterns and conflicts of interests (e.g., investor money). I’d recommend checking out the article if you’re interested in this topic.
Why is an open protocol more important than the act of communication itself?
Open protocols are important because the act of communication is so important. Nobody should in control over the means of communication.
When I check out a new apartment to rent and I see it doesn’t have central heating, I don’t think to myself “ah of course, what a smart design decision, the builders decided to save on complexity” I think “oh they cut corners and either did not renovate in central heating or they don’t care to support central heating, well, not my sort of place”.
Agreed; however, if I don’t notice a golf course in the background I’d probably feel relief rather than anger since that’s a bit more than I bargained for. A golf course isn’t part of the “house spec”. A stable temperature, on the other hand, is part of the minimum requirements for a house and should be included in the “house spec”.
This is the problem that folks bring up when talking about open source adoption. Open source often cares more about principles than usage. FOSS cares more about openness, customizability, and other values that end users care for less than core functionality.
Correct. These are ideological movements. They support ideologies, and reject the notion of the “end justifying the means” (the way the phrase is commonly used).
In the meantime, others will explore other tradeoffs. Like Moxie with Signal
I’ve explained why I find Signal problematic in the previous post. I don’t think one org should own a communication platform.
I think you’d be hardpressed to get any teenager these days to use IRC.
I was a teen on IRC until last year when I turned 20. There are dozens of us!
Also, a quote from this article:
I’m not arguing that average users are doing something “wrong” by doing otherwise; expecting average users to change their behavior for the greater good is naive. This advice is targeted at the subset of users technical and willing enough to put some thought into the platforms they choose, and indirectly targeted towards the people they can influence.
I’m not trying to get the aforementioned stereotypical “teens” to suddently sign up for a FSF membership and install Libreboot (though that would be nice). I’m trying to get technical users to start caring, since they’re the ones who can influence their friends’ technical decisions, file bug reports, and make the software better. That needs to happen for the “teenagers” to sign up.
-
People who are both blind and deaf can use braille readers. Plaintext allows people who are sighted, blind, and/or deaf to interpret language.
Freedom of protocol and implementation is not worth enough for me to relegate impaired readers to second class citizens that someone has to think about. If anything, that sounds like prioritizing the freedom of the able over the freedom of anyone else.
Open protocols are important because the act of communication is so important. Nobody should in control over the means of communication.
For me communication is not worth gimping for the sake of being minimal or implementation-friendly. I am fine accepting complexity in client, protocol, and server to enable users to communicate in novel, ergonomic ways. Communication is much more important to me than implementer ease. I’ll go further and say, given a choice between implementer ease and rich communication, almost everyone would pick rich communication. Only a minority will be so motivated by the spectre of lock-in that they will reject attempts to broaden the platform.
Agreed; however, if I don’t notice a golf course in the background I’d probably feel relief rather than anger since that’s a bit more than I bargained for. A golf course isn’t part of the “house spec”. A stable temperature, on the other hand, is part of the minimum requirements for a house and should be included in the “house spec”.
This is part of your personal “house spec” of course. I think you’re going to have a really hard time finding everyone agree on a “house spec”, and in practice you see folks with very different types of living domiciles based on their preferences. In college, I had friends who lived without central heating and wore thick jackets to use the bathroom. This was their choice.
Correct. These are ideological movements. They support ideologies, and reject the notion of the “end justifying the means” (the way the phrase is commonly used). I’m not trying to get the aforementioned stereotypical “teens” to suddently sign up for a FSF membership and install Libreboot (though that would be nice). I’m trying to get technical users to start caring, since they’re the ones who can influence their friends’ technical decisions, file bug reports, and make the software better. That needs to happen for the “teenagers” to sign up.
For me and many other technologists, technology is primarily about the user and the human component, only secondarily about protocols, implementer ease, ideology, or anything similar. I view technology as slave to the human, not human as slave to the technology. I think you’re going to have a hard time convincing tech users like us otherwise. After all, we’ve had decades of IRC, and even among technologists IRC has lost ground, not gained it. I’m sad to say I don’t think this viewpoint has any bite except among a dedicated few, who will continue to stick to IRC and grumble about new protocols and their freedoms.
“Man is born free, yet he is everywhere in chains”
-
Freedom of protocol and implementation is not worth enough for me to relegate impaired readers to second class citizens that someone has to think about.
I agree, and this is the reason why I think we should build everything we can from plaintext. Audio excludes the deaf, visual excludes the blind, but plain text includes the largest possible audience. Text is the most accessible format in existence, while other formats treat many disadvantaged users as second-class citizens.
I view technology as slave to the human, not human as slave to the technology.
Agreed. In order for people to be in control of their platforms (rather than the other way around), the platform should not be owned by anyone. For technology to be a slave to the user, the technology should be owned by none other than the users themselves.
A lot of your concerns about UX are client issues rather than protocol issues. It’s perfectly possible to build a glossy, animation-rich client with nice colors and icons that can appeal to the masses. The benefit of open platforms is that you get that choice without excluding users on low-end devices who can’t afford to run a fancy Electron app. Open platforms are a means to include everyone and serve the human rather than the platform owner. If your use-case isn’t met, you can build an implementation that meets it.
Minority users matter too.
-
Text is the most accessible format in existence, while other formats treat many disadvantaged users as second-class citizens.
I just don’t agree, and without studies to back this viewpoint up, I’m going to take this as an ideological viewpoint.
Agreed. In order for people to be in control of their platforms (rather than the other way around), the platform should not be owned by anyone. For technology to be a slave to the user, the technology should be owned by none other than the users themselves.
Indeed, but I think you and I have different definitions of ownership. Simplicity and ease of implementation are not prerequisites for ownership in my mind. That simply passes the buck to the technologists, of which ideally we wouldn’t force the entire population to become, much in the same way the entire population does not fix cars and build houses because they are not interested in those things.
A lot of your concerns about UX are client issues rather than protocol issues. It’s perfectly possible to build a glossy, animation-rich client with nice colors and icons that can appeal to the masses.
They aren’t. I want protocol level affordances for things like emoji reactions, custom emojis, threads, and such. On top of that I want the protocol to change as folks want to experiment with new things. Extensibility is a feature for me, not a bug. Also, I don’t really think a world where the UX is left in the hands of “interested” is realistic. Gemini still doesn’t have a rich client because technologists aren’t interested in one, and no surprise, the users are almost all technologists or their close, nerdy friends.
Regardless I think you and I won’t really see eye-to-eye on this issue, so I wish you the best.
-
-
-
-
-
-
-
-
Whether communication itself changes is perhaps debatable – my understanding is that, at least in the technological realm, the tools we have for communicating (e.g. inline images/audio/video, emojis, and what-not) evolve and change, but the underlying needs for expression remain the same.
Sometimes, the constraints of a system determine the patterns of communication, which are then codified into social norms, as you say (IRC favours shorter, plain-text messages, email has “etiquette”, etc.) As more people take part in a platform, it’s inevitable that more and more of these constraints, justifiable as they may be, will become issues that require solutions, features. If the platforms don’t evolve, people will look to move elsewhere, naturally.
The issue here isn’t the features or the changing expectations or even boxed platforms themselves, but rather that extending a platform with no regard for backwards compatibility tends, in the long term, to exclude people from being able to participate as freely as possible, or at all.
Even more so, these “moving” platforms impose their own constrains, which in turn become social norms; people don’t expect to have access to their archive, nor are they expected to be able to see out the lifetime of their devices (though this is an issue way beyond communication platforms.)
Federated or community-owned platforms are better in that regard since interoperability concerns will typically govern their evolution, and thus ensure at least some form of long-term viability and graceful degradation. Extending these platforms with additional features entails more effort, but it does happen – modern XMPP clients are quite feature-ful and pleasant to use, though still behind the various proprietary platforms in some ways. It still, however, remains possible to participate on clients operating against a reduced feature-set (not everyone has the resources to own a recent, or any, smartphone, and there’s workable XMPP and IRC clients all the way down to J2ME.)
It basically comes down to this: for me, being able to communicate without fear of falling out of some compatibility cliff is more important than chasing new forms of expression; in lieu of not being able to say anything, I’d rather not be able to express myself in full colour.
-
the tools we have for communicating (e.g. inline images/audio/video, emojis, and what-not) evolve and change, but the underlying needs for expression remain the same.
I would like to push back on this but have run out of time to offer some examples. At the risk of being hasty, take a look at Sea Shanty riffs on TikTok. That form of cultural expression isn’t happening on IRC that’s for sure. (In fact, the image of someone trying to sing or rap on IRC reminds me of NWA and their entry into mainstream music, but that’s too off-topic to be more than an aside on Lobsters.)
But I agree with the rest of your post. I also think that community owned communication platforms have a greater incentive to respond to and support members of the community because their incentives are not driven by investors or customers in the same sense. I’ve watched the Fediverse take shape in a very community-oriented way and have had my heart warmed by watching folks organize in a multitude of ways (from mods having fun, to co-ops, to corporations) to enable their users to communicate.
-
modern XMPP clients are quite feature-ful and pleasant to use, though still behind the various proprietary platforms in some ways. It still, however, remains possible to participate on clients operating against a reduced feature-set
imagine the following situation:
- you use an xmpp client that is very simple, it only supports plaintext
- you send a question to someone
- they send their answer as an animated gif
- your xmpp client does not support animated gif, you are not able to read the answer.
-
This does, of course, happen all the time, as people participate with less featured clients, or clients that do not support much more than text communication (e.g. terminal clients).
XMPP is actually a good example of how clients are able to fall back to at least a workable baseline, despite any new protocol-level features or changes. For example:
-
For P2P file-transfers (e.g. Streams, Jingle), feature negotiation takes place and the sender is required to ensure that the recipient supports the method used. If not the method will not be offered in the first place, which is arguably better than sending into the void.
-
For client-server file-transfers (e.g. HTTP upload), the recipient will generally see an incoming HTTP URI as a text message, if no other support exists (e.g. for inline display, etc.)
-
For things like threads, reactions/message attachments and the like, context is usually collapsed and the messages will appear as they would normally in the course of discussion.
Ideally, all clients would be able to support all features and these sorts of ambiguities would not exist, but it’s clear that some people aren’t able or willing to participate in the same way as everyone else. And though part of communication is in its intent (after all, a thumbs-up emoji attached to a message is not the same as one posted inline ten messages below), at least these additional features don’t form an “invisible” layer of communication above the baseline.
-
-
-
-
-
I think Matrix is a good attempt at pushing an open product first and an open protocol second. TFA notes that Element is wedded extremely closely to the Matrix spec, which makes it hard to implement, but I think this prioritization of product over protocol is necessary to deliver actual, sticky value to users. Open, federated software needs to enable users firstly; Matrix does document its decisions and open up its spec, but features are driven through the Element experience, which is where the real value for the user comes from.
-
I think there is a lot of truth to what you’re saying, but only up to a point. It’s fine to go the Matrix route as long as there’s a point at which the organization hits the brakes, slows down rapid iteration, and focuses on helping the rest of the ecosystem catch up.
I think that Matrix is at a good point for the feature-slowdown to begin.
-
I’ve tried to onboard friends onto Matrix and they still would like to see more features. Threads come up frequently, and so do custom emojis. We are starting to see more care toward stability in the ecosystem but I think it’s a bit early yet for feature development to stop. Protocol documentation is improving and alternate servers are being birthed (like Conduit). I think client complexity is not explicitly a concern of Matrix, so slowing down now would not help the project achieve it’s goals.
-
-
-
-
a world where applications are spec-driven (or protocol-driven) sounds like a nice place to live, unfortunately i don’t think it works in reality. even if i look at the examples of spec-driven platforms provided by the article, many of those i consider failed:
- email: that thing is mostly broken, because of spam, and when email providers try to limit spam, they have to employ heuristics, which in turn cause problems for smaller email providers (this is even mentioned in the article). no usable encryption too. i think people don’t use email much for communication anymore. for example, in my personal case, most of the communication with friends & family happens through instant-messaging-platforms. my email is for proving my identity when signing up for services, receiving newsletters, talking on mailing lists and getting job offers. so yeah, maybe the last two can be considered communication. but i think you get the point.
- xmpp: xmpp failed for me even without google closing down google-talk. my problem with xmpp was ironically their protocol being extensible ( https://xmpp.org/extensions/ ). (mind you, my experiences are from like 5 years ago, maybe today all this is fixed) this means, you can have an xmpp-client that considers themselves an xmpp-client but it does not support for example file-transfer, or video-calls. in theory we can see a certain beauty there, see, you can create a minimalistic client that can transmit messages through xmpp. on the other hand, this is useless for non-technical users. so, you while you can say that xmpp has many many clients and servers, and that xmpp has many many features, those two are not true at the same time. of course, one approach is to have one well working and well supported reference implementation that does all that is needed, and when talking about xmpp one can point users to that specific implementation…. i think you see where i am going here :-)
- common lisp: the common-lisp standard is from 1994. there is no newer standard. iirc, it does not have sockets for example. so, to write common-lisp applications, you will learn the standard library of the given specific common lisp implementation.
i’m trying to think about applications meant for non-technical users, where the is a “spec” rather than an app. web-browsers are such a thing i guess? and even there, we only have 2 (or 3,depending how you count) “real” implementations.
-
you can have an xmpp-client that considers themselves an xmpp-client but it does not support for example file-transfer, or video-calls
It was (is?) so much worse than that. You could have two clients that implemented file transfer and video calls, but using different extensions and so they couldn’t interop.
One of the big problems here is that most users do not know the difference between a protocol, service, service provider, and app. They see Hotmail or Gmail or WhatsApp as monolithic things. They use the client provided by the service and they see the client, service, and service provider as a single monolithic entity. A few may sometimes use an additional client, but often don’t realise that they’re still using the same service when they do.
Signal gave up on trying to educate users here. The Signal service, protocol, and app are all presented as a uniform blob. I suspect that this is the biggest reason why Signal is the most successful open messaging platform.
-
…but often don’t realise that they’re still using the same service when they do.
And somehow it goes even further! Just the other day a friend told me that her mother got a new Facebook account because she got a new phone and thought her Facebook account was linked inextricably to the physical device she used to access it. I also have heard a number of anecdotes where people sign up for a new Gmail account each time they get a new Android phone.
If people want federation and open protocols to succeed they should stop writing new software and specs and start working out how to explain the whole idea to users and make them care about it.
-
-
i’m trying to think about applications meant for non-technical users, where the is a “spec” rather than an app.
- BitTorrent
- Many parts of the Web and its underlying infrastructure, to varying degrees
- The Fediverse: not as mainstream as social media giants, but still a thriving community with millions of users
- Matrix: despite my concerns, it’s still definetly on the “open” side of the closed/open spectrum
-
The Fediverse: not as mainstream as social media giants, but still a thriving community with millions of users
Fediverse is barely a spec. Mastodon only implemented the S2S portion of the ActivityPub spec and even then only a subset of it. Mastodon still uses a bespoke API to talk to its clients and the client/server situation is a mess. The only 3 well-supported S2S implementations I know are Mastodon, Pleroma, and honk. I don’t even want to get into all the issues with ActivityPub.
-
-
BitTorrent was originally the name of both the protocol and the client. Later people used the same protocol to build other clients, but the original model wasn’t too different from e.g. Signal. This is probably a major reason for its success. If it had used the “XMPP model” of just publishing a specification (or a specification with a client as an afterthought) then it probably never would have become as popular as it did.
The same more or less applies to the web: Berners-Lee didn’t just publish a bunch of specifications, he published a HTTP server, web browser, and web editor. And the web’s later mainstream growth was driven by products (Netscape and IE mainly) rather than specifications.
-
To be fair, Jabber was the protocol of a reference implementation with corporate backing first, then the IETF spec came later. That was just so long ago in internet years that it’s barely relvant anymore
-
-
Neither were ever a “closed” platform; it’s just the difference in focus/communication:
-
Publish an open protocol, market/communicate the protocol, and wait for people to write clients for it.
-
Publish and open protocol and write a good (or at least decent) open implementation of it, and mainly advertise the implementation rather than the protocol.
-
-
-
-
common lisp: the common-lisp standard is from 1994. there is no newer standard. iirc, it does not have sockets for example. so, to write common-lisp applications, you will learn the standard library of the given specific common lisp implementation.
Not necessarily, take the example of sockets. As the language is extensible, a library can abstract over implementations extending the language. The same applies to threads, for example. Then all other libraries depend on these projects, instead of implementations.
-
-
interesting interview-question, my problem with it is that the required effors totally depends on whether your language has this builtin or not.
for example, look at the python solution:
[(a,len(list(b))) for a,b in itertools.groupby('aaabbbbbbcca')]itertools.groupbydoes all the work, you just format the result to the required specification.the article used
clojurewherepartition-byseems to do the same.if your language does not provide this function, you will have to reimplement it, or do something else. my point is, the effort is a lot larger.
to take the argument to the extreme: imagine the interview-question is : “how to reverse an array”, and some candidates use languages where “array.reverse” exists, and some use languages where it does not exist.
-
from the article: “Does this really count as mutability though? Not really.”