> So my take is that music streaming platforms do zero quality control.
Where's the line between that and requiring every service that allows media uploads to build a YouTube-esque content ID system, that would cost north of €/$/£100m and still be inaccurate/gameable?
inb4 "extracting monetary value" - can you come up with a fair definition that still clearly and unambiguously allows e.g. an aspiring opera singer to upload a demo of their own performance with their CV/application?
20th century's ideas of copyright have so far scaled incredibly poorly into the digital age. 30 years ago nobody expected an average (but highly motivated) Jane/Joe to be able to afford recording an album OR launching a company literally from their bedroom, yet both are now everyday occurrences.
Once you have 3 environments (which IMHO is the minimum viable number: dev, staging, prod), it tends to be much easier to generalise that to N, at least from the application side (spinning up the extra infra is a separate beast). It tends to weed out many of the "if (prod)"s because there should now be differences between dev & staging that you need to take care of, and sprinkling elaborate switch statements gets tedious really fast - most devs tend to be happier actually simplifying code.
I've seen some really nasty offenders though, e.g. actual business logic hidden behind an "if (window.location.hostname == ...)". Sometimes it takes a lot of patience to explain that this is how you get production-only bugs that QA will never have a chance to find or reproduce.
Depends on what you consider "easy"! Nix itself has a pretty high barrier to entry.
Personally I believe systems that start simple (e.g. Alpine) are easier to mess with. Plus you don't have to give up all benefits of declarative configuration; for example apk has a single file (/etc/apk/world) that defines the exact package set that needs to remain installed. You can edit it and run "apk fix", much like you can edit /etc/nixos/configuration.nix and rerun "nixos-rebuild switch". It's not as powerful as Nixos, but power (and complexity) always has a price.
> Using a different language to depend on packages derived from .nix would be very much akin to depending on a docker image whose Dockerfile you can not inspect.
Speaking of Docker images and Dockerfiles, that's actually a real-world example of how you can achieve this kind of effect without relying on a specific language. Ironically, you can use Nix to build Docker images; there's a bunch of other alternative builders (e.g. Kaniko, Buildah); you can also just stitch together some files&metadata into tarballs, and then 'docker import' it.
Nix or Guix are of course much more powerful and expressive than Docker images, but there's always a cost to complexity.
To be fair, we (myself included) look at you weird because the ZFS folks haven’t done a great job at extolling its virtues in a way that the average consumer can comprehend. It’s important to acknowledge that the vast majority of consumers simply don’t care about the underlying file system or its capabilities, even if they would benefit immensely from the features of something like ZFS.
It’s a problem of communications as much as it is vendor support. If you get the consumers wanting it, vendors will switch to it. Instead, right now we get companies like Apple reinventing the wheel via their own proprietary FS just to adopt some features of ZFS, rather than _just supporting and contributing to ZFS_.
Which means I get to anxiously eye the Synology with btrfs instead of resting easy with ZFS. It’s better than ext4, but I also know I’m the exception rather than the rule.
MPRIS is an under-appreciated standard and a great example of how different technologies on the open desktop should integrate with one another.
For example, there's <https://github.com/altdesktop/playerctl>, which can control any MPRIS-compatible client: VLC, web browsers, different music players, mpd (with a plugin), etc.
MPRIS can also be used to e.g. allow controlling playback without unlocking the screen - the screen locker itself doesn't need elaborate support, something as simple as slock could be hacked to recognise a key combo and call out to playerctl; more fancy login managers/lockers could talk DBUS/MPRIS directly and even e.g. display album artwork.
Unfortunately, the standard doesn't seem to specify a simple way to indicate whether video is being played back, which could be a saner way to inform the screen locker; the actual protocol to directly inhibit locking is unfortunately a little bit insane.
Funny you mentioned playerctl. Due to the fact that over time its scope expanded from a simple MPRIS based control application, into a full blown library with various unneeded (by me) features. Therefore as a starting point for the scrobbler daemon I wrote the simpler mpris-ctl: https://github.com/mariusor/mpris-ctl, which does just the control and meta-data output parts that playerctl has, and only depends on libdbus.
And concerning your last point, are you advising someone that built at least one MPRIS tool to read the spec? :P
> And concerning your last point, are you advising someone that built at least one MPRIS tool to read the spec? :P
The whole comment was for the general HN audience who might not be aware of MPRIS.
The general problem I keep seeing is silos; we've had the XDG standards/specs for decades, yet keep reinventing new, stupid, and broken ways to do things. Under X11 it was normal that every window got a border; under Wayland, GNOME doesn't want to adopt a protocol where a window can ask the compositor to paint a basic border, instead tells SDL to link against libadwaita. XScreenSaver has been telling apps to do "while sleep 60; do xscreensaver-command --deactivate; done" which worked well enough for decades; to "modernise" that, we have a DBus protocol which makes an app grab a cookie, and if it fails to return it (e.g. because it crashed) - the screensaver remains inhibited forever. Trying to use (or improve upon) a FOSS desktop is death by a thousand papercuts.
That's why you need editor support for this; the lexer understands the difference between an operator and a string literal (that's how syntax highlighting works), and should be able to use ligatures in one context but not the other.
(BTW I'm not a fan of coding ligatures myself, but they seem to be popular.)
Yes, if you do it on top of the lexer it starts to make sense to me. I still think the language should also support the corresponding "ligatures", so that no confusion can result if you happen to enter ≤ directly, but this is actually a nice solution to the problem of what to do in your language aware editor when the user enters <= : nothing! You just assign to different token classes different fonts.
IRC does not store messages, it only relays them to clients. You need an add-on solution to store chat history, something we've been taking for granted for ~30 years.
IRC all but requires using a bouncer to follow a conversation from more than a single device.
IRC does not encrypt messages, only (optionally) the client<->server connection. Without E2EE, you have no privacy against the server/operator, which is an easily targeted SPOF.
Matrix (the protocol) is still in flux, and the implementations are lagging behind the spec. If you're not using Element, you're behind on features and security.
XMPP is (similarly to IRC) relying on optional protocol add-ons for basic things, like E2EE, which clients may or may not support fully or correctly.
2013/Snowden happened 11 years ago. E2EE should by now be considered a basic feature, a commodity, something we should be calling for as relentlessly as we did for HTTPS. (Discord of course does not implement E2EE.)
Truth is, E2EE isn't a "basic thing". It's an add-on feature that most people don't want. It is impossible to have E2EE that doesn't leak into the UX, and most people would rather have a streamlined UX than deal with key management. It is also much more complex to have robust E2EE in a group chat.
The thing that sets E2EE apart from HTTPS is that HTTPS requires nothing from the end user. It just works. And as a site owner, you just set it up once and forget about it.
> It is impossible to have E2EE that doesn't leak into the UX
True, but one is also free to study the UX solutions implemented on platforms such as iMessage, WhatsApp, and Signal, which all have strong E2EE and see plenty of mainstream usage.
> [...] HTTPS requires nothing from the end user.
Depends on how you define "nothing". We've collectively put an insane amount of work to bring HTTPS to where it is today. Also, HTTPS continues to rely heavily on each server operator's skills and diligence.
There's also plenty of edge cases where HTTPS clients need to go an extra mile, such as containers (many base images do not include a cacert bundle), IoT/retrocomputing/other underpowered devices, and so on. There's always a cost, but it's usually worth it.
On iMessage, your keys are managed by Apple. You effectively fully trust them (which seems to be the assumption in most of Apple products anyway). I wouldn't call this a "real" E2EE implementation.
In WhatsApp, you're limited to one device logged into your account, and the rest are proxied through it. And message backups, those are annoying.
In Signal, you have all those stupid backups too, and while you're able to log into multiple devices (it seems), your past messages don't load "for your own security", and there's also this stupid time component so you get logged out on your computer if you haven't used the Signal desktop app for some weeks (which I don't).
Whereas on Discord, Telegram, Slack and other IM services without end-to-end encryption, you log in on a new device and that's it. You instantly get access to all your messages since the beginning of time, and stay logged in forever.
> On iMessage, your keys are managed by Apple. You effectively fully trust them (which seems to be the assumption in most of Apple products anyway).
I'd argue there are many scenarios in which this might be preferable to a lengthier/wider supply chain. Personally I'd sooner trust Apple than Microsoft+(Lenovo/HP/Dell/...)+(Intel/AMD/Qualcomm/Broadcom/...)+(every device with DMA (PCIe/TB), unless you trust your IOMMU)+(.../...)... (you get the point). And the alternatives to Microsoft are each its own kitchen sink.
> In Signal [...] your past messages don't load "for your own security" [...]
I agree that this is quite annoying. HTTPS clients resolved a somewhat similar problem (usage of self-signed certificates) by trusting the user to make an informed choice. I wish Signal would trust their user base to make their own choices there as well.
> Whereas on Discord, Telegram, Slack and other IM services without end-to-end encryption, you log in on a new device and that's it. You instantly get access to all your messages since the beginning of time, and stay logged in forever.
Same with iMessage. Whether this is a feature or a bug, depends on your threat model.
But we're in a situation where we don't even get to make an informed choice - every solution (as you pointed out) comes with its own bag of UX shortcomings. These trade-offs should be user choices, not something the vendor forces upon you. But these are not fundamental shortcomings of E2EE as a concept, but particular issues with its different implementations. WhatsApp shows you can restore messages from a backup; Signal shows you can have "real" multi-device presence; etc. If we could spend 1/100th of the effort we did to push HTTPS everywhere, E2EE could be just as ubiquitous today.
Just spitballing, but couldn't you have a new device login as three fields, username, password, and encryption key? Then if you don't add the encryption key you don't get the history, but still access the account. Then if password managers really saved all three, then would simplify it for more people (at least those with password managers). But there still has to be a cultural shift for a lot of people to password managers asking non-tech people
> On iMessage, your keys are managed by Apple. You effectively fully trust them
Not really? You can choose whether to upload your recovery key to iCloud or not. The software abstracts over the details of course, but Signal does that too. Unless you're arguing that it's impossible for closed source software to have "true E2EE", which may have some merit, but Discord is proprietary, and something is better than nothing.
> IRC does not encrypt messages, only (optionally) the client<->server connection. Without E2EE, you have no privacy against the server/operator, which is an easily targeted SPOF.
Same as Discord.
> Matrix (the protocol) is still in flux, and the implementations are lagging behind the spec. If you're not using Element, you're behind on features and security.
Discord also only has one reference client, but for me even with that client Matrix/Element was not as reliable. I still use and like it, but it's not a like for like in that regard.
> XMPP is (similarly to IRC) relying on optional protocol add-ons for basic things, like E2EE, which clients may or may not support fully or correctly.
But if you use current clients like Conversations or Dino or the likes it does work. There is no point in counting the clients that don't support it if these aren't the reference or biggest ones. The problem here is more that it's not meant to be used like Discord in any way. Not for big group chats/channels nor for big voice chats (not even sure this possible).
> IRC does not encrypt messages, only (optionally) the client<->server connection. Without E2EE, you have no privacy against the server/operator, which is an easily targeted SPOF.
FWIW this point isn't relevant to the IRC vs Discord discussion, since Discord is also very not E2EE. That said, XMPP my preferred protocol that checks all of the boxes.
I have stated that at the end of my original comment. I'm not advocating for Discord (merely enumerating IRC's and XMPP's shortcomings), but I would like to point out once again, that post-2013 any solution that does not enable strong E2EE by default should not be advocated for - at all.
> That said, XMPP my preferred protocol that checks all of the boxes.
Read up soatok's breakdown on the design & status of OMEMO. I'm not a cryptographer, but I do trust a cryptographer when they say some protocol's design/crypto is broken.
Maybe for your your use. For my use, not a single thing that goes over discord are things I'd object to being posted on a public website. That includes DM's. Not having E2EE means something isn't a solution for actually private conversations, but a lot of conversations happens in setting that are not actually private in any sense.
But Discord & IRC aren't generally private spaces. They're no different to web forums in that you would reasonably expect that something you write today would be accessible without reference to you in 10 years hence.
That's a very different proposition to a private/group message exchange in WhatsApp/iMessage etc.
I get that, I wasn't passing judgement. You guys must be super sensitive to be downvoting me for just sharing another point of view.
Personally, I find xmpp and IRC to be easier ways to talk to friends and interest groups when they use those networks. The software is simpler, faster, and a better experience for me.
Matrix is a bit of an exception where it's slow and buggy and barely hanging on.
But me and my friends don't care about discord stickers or nitro or giphy links or the discord store or any of that kinda stuff that you go to discord to use. And thats fine if you do.
People can want and enjoy different things and also "want to easily talk to their friends or interest groups without having to worry about it."
I do consider it a feature, in hindsight. Learning to program by asking "dumb" questions was great, because chats were ephemeral, nobody cared if the same question was asked for the 10 millionth time or risk of embarrassment being like 12 years old and asking greybeards for help.
Nobody also felt bad saying "RTFM" because, whatever, it blows over in a minute, there's no permanent record of having a harsh moment, more free to just move on.
The same old questions being asked due to no search also provided more opportunities to answer those questions, so, newbies could start to learn by teaching.
So, yeah, I think something beneficial was lost, even if I wouldn't go back to that approach- it's more of a tradeoff than a definitive improvement
> I do consider it a feature, in hindsight. Learning to program by asking "dumb" questions was great, because chats were ephemeral, nobody cared if the same question was asked for the 10 millionth time or risk of embarrassment being like 12 years old and asking greybeards for help.
I pity the new generations for not having this kind of opportunity: the opportunity to make mistakes, say dumb stuff and goof off with all these things vanishing in a matter of minutes, hours at most.
I miss the old internet: at any point you could pick a new nickname and get a fresh and clean new email address from many of the webmail providers and just start a new online life.
And it was considered normal. It was actually a "best practice" to never use nicknames.
This approach simply doesn’t work when users are allowed to vote or have any sort of scoring mechanism. Since bad actors will also create multiple “online lives” and manipulate those systems with a few clicks
Remember when phrases like "Never use your real name online" used to be near universal? Yeah, this is something I also miss about the old Internet.
Like, even back then you could absolutely tie your IRL identity up with your online identity, but the difference of course was that it wasn't a requirement of existing online, like it is now. Like yeah, you can stay anonymous but a) it's super difficult since the modern day assumption is that you're not doing that and b) that you're up to no good, because why would you be hiding who you are, unless you were doing something shady. And now even "normal" people lament just where we went wrong and what happened to online privacy. To the aware, privacy dying like this was clear as day, but I suppose most just didn't hear, or chose to ignore, the alarm bells.
And now everything is logged, analysed, and associates with the people who produced the messages and other sundry content. There is no ephemera, we need laws just to be forgotten by services (as an EU citizen, I'm glad about law existing here, but it shouldn't need to be a law, it ideally should be assumed), and we're constantly getting watched by both states and surveillance capitalists alike. Not actively in most cases, mind you, but passively, with our movements, our interactions online, and just what we do, just getting aggregated into these humongous data sets of Big Data, to train statistical models on. Mostly to surveil us even harder, or to manipulate us in the form of advertisement, which can be even more insidious in some ways.
I'm sure that stuff like the Cambridge Analytica fiasco could have occurred even without this destruction of privacy, anonymity, and ephemeral content, but I posit that it would have been way more difficult had people not been encouraged to put everything about themselves into services that would log them and build evermore complex models about them and their thoughts. And now this kind of stuff can be used to destroy democracies, and as alluded to earlier, manipulate for example our spending habits. And now we all wonder just where this all went wrong.
It also creates an echo chamber effect, X is popular so we make more X.
Our culture is already revolving around rehashing what's "proven". The most original and interesting ideas may come from those who oppose that trend, and these ideas are most likely to drown in the sea of slop.
Also the "content" "creators" who are most likely to benefit from tracking are the giant corporations - we're just making the rich richer.
Where's the line between that and requiring every service that allows media uploads to build a YouTube-esque content ID system, that would cost north of €/$/£100m and still be inaccurate/gameable?
inb4 "extracting monetary value" - can you come up with a fair definition that still clearly and unambiguously allows e.g. an aspiring opera singer to upload a demo of their own performance with their CV/application?
20th century's ideas of copyright have so far scaled incredibly poorly into the digital age. 30 years ago nobody expected an average (but highly motivated) Jane/Joe to be able to afford recording an album OR launching a company literally from their bedroom, yet both are now everyday occurrences.
reply