emma wrote

Are we simply trusting that they are using the same code?

Pretty much, yeah.

In theory, you can verify it's built on the source by compiling it yourself and comparing the output to the prebuilt version. There's a whole methodology called reproducible builds meant to enable this verification, and supposedly Signal supports this.


emma wrote

I keep telling people we should just tack "-over-HTTPS" to every network protocol so we can leverage the affordable, widely available DDoS mitigation infrastructure that's meant to protect websites.

SourceHut looks nice, and if I were still actively programming, I'd gladly try it out. It sucks to see this happen.


emma wrote

Reply to comment by 2elddar in Free Software vs. Open Source by plank60

Good god that thread is funny. Threats of reporting the copyright holder to some ominous group for violating their own rights as the copyright holder.

I can see that you are active in other threads, you are breaking the contract (GPL3) by not sending me sources. You are being illegal.

Best imagined as dialogue from Ace Attotney.

Idk why, but any discussion about copyright and free software just seems to invite a ton of insights from people who don't have even a basic understanding of any of them, as demonstrated both in that thread and here.


emma wrote

back when GitHub switched away from master/slave branches.

Gonna expand on this a bit. Git, the technology that Github uses, had 'master' as the default branch name, but 'slave' wasn't used anywhere. However, one version control system that inspired Git did use it, therefore it was argued that Git's use of 'master' was part of the master/slave dichotomy.

I was one of those who renamed branches from 'master' to 'main' back when the George Floyd thing happened, but in hindsight I feel it was an incredibly performative action to take. Not only was the rationale incredibly contrived, but the tech companies that pushed for this were also perfectly happy selling their services to a US government agency that hunts down immigrants, breaks up their families, and locks them in cages. So from my perspective, that whole endeavour was incredibly pointless, and played into a PR campaign to launder the reputation of harmful companies.

But that's just my perspective as a white person living in Europe, and maybe other people here feel differently about it. If anyone has perspectives to share about either 'master' or 'whitelist', please let me know, as I'll take these into account when deciding whether to change the wording in Postmill or not.


emma wrote

Autocomplete is as much cheating as using a premade template.

I don't agree with this, like this is one of the benefits of having a schema, and is painful to work without once you've gotten used to having it.

Even if you weren't using autocomplete, it's much easier to search through documentation for <tag> than it is to search for array/object structures.

But would you not still be at the mercy of your editor having an autocomplete plugin for the specific XML schema you're using?

No, the XML schema is just an XML document describing how other XML documents that use it should be structured. So you need one editor and/or plugin that supports such schemas, and then you have autocomplete for all your XML documents.

For the same reasons, if you have a schema, then you can perform the same validation of XML documents anywhere.

To some degree, this can be achieved with JSON using JSON Schema, but it's not as ubiquitiously supported as XML.

Do other languages not have equivalents?

They do, but you easily end up with discrepancies in how two systems would parse the same document without using a schema when everyone's defining their own way of validating stuff.

I've got nothing to add here, I just want to thank you for vindicating my nightmares

No problem. Thank you for attending my In Defence of XML TED Talk.


emma wrote

Hello {} remember to drink your water

Now you need a bunch of post-processing to deal with string templates.

If I wanted the friends to be able to have attributes I'd have represented them as objects

If you don't own the system, and you need to stay interoperable with a spec or other implementations you can't change (e.g. XMPP), you cannot do that. In XML, it's a given that all your friends would have been represented as <friend> tags from the outset, as shown in your example.

Doesn't pydantic do that for you?

Yeah, it'll work for the purpose if you're OK with coupling your spec to the implementation. If you're building an open ecosystem, and you're inviting people to come make stuff for it, then that's the point you begin to care about well-formedness, and want the schemas written in a declarative format so they can be read with things that aren't Python.

Alright lass, write me an apache config file without refering to an example, if XML structure is so self evident.

Assuming it was XML (it's actually some hellish thing that looks like it, but is hugely different), I could easily do this since I'd just get autocompletion for all the things available to me. Not so easy with JSON if your editor doesn't know what the hell it's looking at.


emma wrote

Unlike say JSON, there's no differenciation between int literals and strings representing the same int. [...] It's somehow [...] more ambiguous than JSON.

The int/string situation is entirely avoidable by specifying the situations where something is a string and where it is to be treated as an int. For instance, by using schemas.

Can you imagine why basically nobody likes XML in the data interchange world?

And yet, so much effort is wasted trying to graft support for things in XML, like schemas, paths, and namespacing, onto other formats, resulting in abominations like JSON Schema, JSON-LD, JSONpath, and YAML. In the end, they don't end up with anywhere near the same ubiquitous support that there is for XML with all its features.

Your example isn't entirely fair. Try representing a DOM tree in JSON, or adding additional attributes to any of those friends in your example for the benefit of a third-party application that won't know about these attributes, or allowing the friend names to contain arbitrary machine-readable markup, or just having a multiline string. XML copes well with all of these situations, but the alternatives, not so much. The larger size of an XML document isn't anywhere near as bad with gzip applied, and with a streaming parser, you don't need to hold the entire document in memory to parse it.

Yes, XML is very verbose, and it isn't sexy, and it's probably not the right choice for an instant messaging protocol, and if all you need is simple key-value exchange, then by all means, JSON is fine. Once you want to enforce well-formedness without writing piles and piles of validation code, or add to the document in a way that's transparent to the consumer, or just have a self-describing config file where the human recipient doesn't have to look up that something should be an array of array of objects with these particular keys, then it all begins to fall apart, and you'll want to use a more feature-rich format. Preferably without resorting to a half-baked reinvention of the wheel.


emma wrote

To set the record straight on things that have been said here:

Passwords are going to be hashed using either bcrypt or argon2, leaning towards the latter if it's available server-side (I assume it is, but I haven't checked). Both are considered very secure, but I keep hearing that argon2 isn't as great as once thought.

As for why it's like this, Postmill used bcrypt exclusively, but then Symfony deprecated the "bcrypt" hasher, and told everyone to use the non-descriptive "auto" or "native" hashers instead (which can use either algorithm internally). Then they figured obscuring the choice of algorithm was a mistake, so they reverted the deprecation. In hindsight I wish we'd never switched, but I don't know if it's possible to revert back without breaking existing logins. It's become very common for Symfony to dig holes for you to fall into and deprecate everything and cause headaches for poorly thought out reasons, and this is why I don't start new projects with it.

Credentials are transmitted securely (end-to-end encrypted) to the server via TLS. Stuff like keyloggers and MitM attacks via proxies and such things that have been discussed here are completely outside our control, and there's not much, if anything, we can do about such situations, nor should the burden be on websites to handle them.


emma OP wrote

Yeah, it's not copyright assignment like I initially assumed, but you're still giving a for-profit company the right to do basically whatever with your contribution, while everyone else is subject to AGPL terms. Regardless of their stated intent, they could still relicense Synapse in the future. I still think it's a bad deal, and that no one should sign the CLA.