Ask HN: How much documentation is enough? - <AUTHOR>

I'm interested in how much technical documentation startups generate during the pre-launch phases. I'm particularly interested in YC invitees as they are in a very timebound context.
In my one-man setup, I generate enough documentation to sketch out the main user flows through the app; a broad technical architecture and a feature roadmap. I do not document detailed technical and functional spectifications, nor do I write detailed test cases.
I guess the question I am asking is whether I am storing a world of pain for x months / years hence by adopting such a lightweight approach... <comment><USER2> I've found that when I write documentation as I go along, I tend to document the wrong things. It's a bit like premature optimisation: you're in the thick of it, hyper-focused on whatever seems the hardest part of the problem at that stage. You document what's on your mind. As with optimisation at that stage, you're usually wrong.

So I've found you need to try to develop a sense for the sweet spot: the point in time where things have settled down a bit and you're seeing more of the big picture, yet it's all still completely clear in your mind and your memory hasn't been diluted by the muddy waters of time.

I suppose for a startup, the key here is the _time where things have settled down a bit_. I have no startup experience to speak of, but the impression I get is that that time can be a long way out. Almost certainly longer than you expect, as you iterate again and again and try to figure out what it is that users _really_ want.

The other thing you need to ask yourself is why you're writing the documentation in the first place. Is it for potential future developers? The documentation isn't going to replace digging through the entire code for them. Most if not all documentation that I've encountered which attempted to serve this purpose was woefully inadequate and basically redundant. _If the code is well-written, it usually documents itself, and if it isn't, you need to read it anyway because it's probably impossible to encapsulate all its subtleties in prose._

So internal developers are out. Who else comes into contact with your tech? Well, maybe you have non-programmer cofounders/employees who need to generate data in certain formats. You'll need to document those, no doubt, once the formats start to stabilise. Better still, get users of the docs to write them for you or with you. This sounds lazy, but actually their thought process is different, and future users will think more like them than you. Of course, check over the result for errors and inaccuracies.

Another group of people that will need documentation appears if you have some kind of outside-facing API. These people will usually not have the opportunity or inclination to trawl through your source, so as with the file formats example above, to the intended readers of the docs, the docs are the _only_ source of information. I guess this one is really obvious, but I'm going to point out that the design of your API will be more important than nailing the docs for it. Iterate. An elegant API requires little introduction.

So these days I worry more about the quality of the code than the documentation, and I write docs only for those who won't come into contact with the code directly.

(NB: you can probably tell I've given this sort of thing a _lot_ of thought, and have had extended discussions with other developers about the subject. Take all of the above with a grain of salt - many people will vigorously disagree with a lot of it. I'm also working on a project off-and-on that kind of explores this space; unfortunately earning money to stay alive is consuming my time at the moment)

</comment><comment><USER3> What you are doing sounds like the right level of detail. When I take over a project, I like to have an architectural overview so that I have a context to work from. Detailed but wrong is worthless. One important piece that I often find missing is a short narrative about each table in the database.

I write short architectural papers as I go along, mostly to get feedback from interested parties. I do the "official" documentation at the end.</comment>


Determining an Election in K - <AUTHOR> http://leahneukirchen.org/blog/archive/2020/03/determining-an-election-in-k.html <comment><USER2> Another approach to the 'highest averages' method, using a k9 dict:

        v: 10400 3400 6200
        s: 15

        quotients: ,/v%\.5+!s
        labels:    s/!s*#v              / list of 15x 0, 1, 2. arbitrary; could instead be party names
        top:       s#>labels!quotients  / k dicts can have duplicate keys; can sort items by key(^) or val(<>)
        seats:     `freq@!top           / count appearances of dict's keys

The ability to transform a dict's values while keeping the labels (keys) unchanged - sort, arithmetic, etc - is really powerful.

This answer is longer when minified, but it's faster in 2020.03.27:

        \t:100000 +/s>(#v)^<>,/v%/.5+!s           ⇒ 1494
        \t:100000 `freq@!s#>(s/!s*#v)!,/v%\.5+!s  ⇒ 691

<comment><USER2> Correction: I think the above can be a bit faster and shorter if we skip the dict, and just index into the keys. Compare:

         \t:100000 `freq@!s#>(s/!s*#v)!,/v%\.5+!s
        941
         \t:100000 `freq(s/!s*#v)s#>,/v%\.5+!s
        901

</comment></comment><comment><USER3> Always a pleasant surprise to find niche or mundane uses of array languages. I really appreciate the explication because it made it possible for me to follow along in J - there's vanishingly little material to patiently explain bits like the "grade-up grade-down to return rank" that permeates so much APL-style code.

I'm similarly pleased to have found a correspondence from K's _'_ (also present in Klong) to J, where it ends up being _" 0_ in this instance.

        r=. v&%"0 (0.5+i. s)
        +/s>($r)$/:\:,/r

</comment><comment><USER4> A nice demonstration of how the K REPL can be used as a calculator and exploratory tool. The concise syntax particularly shines in interactive cases.

<comment><USER5> > The concise syntax particularly shines in interactive cases

If you can tolerate the learning-curve though.

For comparison, I do appreciate that many (most?) Linux shell utilities and command-line programs in general have adopted standard conventions for arguments (-f for short, --full for verbose) which make it easier for people new to a program to take a cryptic command-line and look-up the full-versions of the abbreviated commands to see what's going on - PowerShell does the same thing with its strict aliasing of cmdlets. Unfortunately I can't see that K (or many other programming languages really) do the same thing, where a a short, cryptic program can be syntactically expanded to one using verbose syntax with no changes in program semantics (unless you count VB.NET vs C# equivalence, heh).

Is there any automated explainer tools for the K language for beginners?

<comment><USER3> Not long ago there was a post about using English language instead of the J symbology[0] but the end result isn't meaningfully easier to understand because of all the prerequisite knowledge of how evaluation works etc., once you've worked that out most of the "line noise" has already sunk in. I think that's a big sticking point against creating a second "inflatable" notation - though there is always Nial[1]

Not entirely an answer to your question, but J provides introspection/help in a pretty direct way via two distinct means, the first is _;:_ ("words") which will show you the parse of a J phrase (here, a pretty direct translation of the algorithm in the article):

        ;:'+/s>(s,#v)$/:\:,/v&%"0 (0.5+i.s)'
        ┌─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬──┬──┬─┬─┬─┬─┬─┬─┬─┬─┬───┬─┬──┬─┬─┐
        │+│/│s│>│(│s│,│#│v│)│$│/:│\:│,│/│v│&│%│"│0│(│0.5│+│i.│s│)│
        └─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴──┴──┴─┴─┴─┴─┴─┴─┴─┴─┴───┴─┴──┴─┴─┘

Which shows the tokens of the phrase, which can be helpful if you are unsure of where a symbol or diacritic is being used. Inside the J IDE you can get context sensitive help by pressing Ctrl-F1 on a symbol, if you were interested in _/ :_ for example, you are directly linked here[2].

I am unaware of a similar tool in K, which should not be taken to mean it doesn't or can't exist. One of the reasons I'm interested in J has been the tooling and documentation available.

[0]: [https://wjmn.github.io/posts/j-can-look-like- apl/](https://wjmn.github.io/posts/j-can-look-like-apl/)

[1]: [https://tangentstorm.github.io/nial/intro.ndf.html](https://tangentstorm.github.io/nial/intro.ndf.html)

[2]: [https://code.jsoftware.com/wiki/Vocabulary/slashco](https://code.jsoftware.com/wiki/Vocabulary/slashco)

</comment></comment></comment><comment><USER6> This is concise in a sort of code golf way, but not substantially faster to write than equivalent R code -- I chose R because math operations are natively vectorized and the basic data type is a vector, and because the language has a user-friendly REPL -- would be, and certainly less readable. I read the linked K documentation and it seems like much of K's syntax was motivated by wanting to get away from "the programmer way of doing things", but the lack of readability would seem to get in the way of that.

Still neat as a toy exercise using what seems like a fun little micro- language.

<comment><USER7> Do you consider add(a,multiply(b,c)) certainly more readable than a+b*c?

The article shows some nice k idioms that I find much more readable written in a concise form. For example, I find |^... easier than reverse(sort_ascending(...)), or <>... easier than grade_down(grade_up(...)). I guess the solution in other languages would be to define more functions for all these common operations, but then you will need much more documentation for all these extra functions and learn them, so I don't see it as an improvement.

At difference of most golfing languages, the set of k primitives is very small. Many people who criticize k forget that property, but it's a very important one. It would be interesting to see the R version and compare the amount of documentation you need to read to completely understand what each of the programs is doing (ie. to read the program). That would be, in my opinion, a better measurement of readability than a subjective opinion (unfortunately, the k9 documentation is too scarce at this point to make this exercise in a proper way).

<comment><USER8> > Do you consider add(a,multiply(b,c)) certainly more readable than a+b*c?

No, but it took me 12 years of school education to get to that point. Question is, for a large code base how many symbols are you willing to remember? At some point it hits diminishing returns, doesn't it?

<comment><USER7> Well, 12 years is an exaggeration. Once you have learned the concepts (which you need to learn independently of which programming language you use), getting used to the symbols is just a matter of a bit of practice. For example, I learnt to multiply with 3x2, but it did not take me 12 years to get used to the 3*2 notation used by most programming languages.

The symbols you have to remember are the ASCII symbols (most of them are used in other programming languages too), with two operations for symbol, plus a few special cases and a bunch of extra functions. In total, less than 50 primitives. I think that any programmer can easily handle that.

There are many people who do not agree with this, but there is objective data (see the papers by Iverson about his efforts to teach mathematics using APL) that say it is easy to learn. In all these threads, most people with experience in array languages say it is not so hard as it looks, although there are some exceptions.

You may prefer other kind of languages or other kind of notation. There certainly is some subjective factor here. But I suggest everyone to give it a try before forming an opinion.

</comment></comment></comment></comment><comment><USER9> I suspect the Python or Haskell equivalent of

        _q+(s-+/_q)><>q-_q:s*v%+/v

would be longer, but it would also probably be more readable.

<comment><USER10> The only difference is a matter of alphabets. Is English more readable than Japanese because the words aren't as condensed?

</comment></comment><comment><USER11> Though I would miss the daily K post, but here it is!

</comment><comment><USER12> K definitely meets my criteria for being a _Write-Only Language_. I remember a quote about APL (a precursor to K) being "indistinguishable from line noise".

[https://en.wikipedia.org/wiki/Write- only_language](https://en.wikipedia.org/wiki/Write-only_language)</comment>


Markov processes and the second law - <AUTHOR> https://guille.site/second-law-markov.html <comment><AUTHOR> Author here! Feel free to ask any questions :)</comment>


Curated list of cool Aliexpress electronic kits and modules - <AUTHOR> https://alitronik.com/ <comment><USER2> I wish there was a place where I could post a project I worked on and get a cut of the sales of the parts list.</comment>


At high pressures, potassium adopts a mix of crystalline and liquid structure - <AUTHOR> https://www.nationalgeographic.com/science/2019/04/new-phase-matter-confirmed-solid-and-liquid-same-time-potassium-physics/ <comment><USER2> It's great that the popular press still runs science articles.

What's not so great:

1\. There is no link to the original paper.

2\. The description of the phenomenon has been so contorted that it's impossible to understand exactly what was found or its significance.

The article notes:

> "Somehow, these potassium atoms decide to divide up into two loosely linked > sub-lattices," Hermann says. But as scientists turned up the heat, x-ray > images showed the four chains disappearing, and researchers argued about > what exactly was happening.

Fine, there's debate about how to explain the experiment.

> The computer models confirmed that between about 20,000 and 40,000 times > atmospheric pressure and 400 to 800 Kelvin (260 to 980 degrees Fahrenheit), > the potassium entered what's called a chain-melted state, in which the > chains dissolved into liquid while the remaining potassium crystals stayed > solid.

That's just one explanation consistent with the data. Clearly, there are others.

The article gives the false impression that some smoking gun has been found. Far from it.

</comment><comment><USER3> How can a computer model prove the existence of something physical? Wouldn't it have to occur in real life before they can make this claim?

<comment><USER4> I can't read the research article now, but from the press article, it looks like they are explaining a known experimental result that was unexplained (or confusing) until now.

IIUC in a previous real life experiment other group put a tiny amount of Potassium under very high pressure, and they uses x-ray diffraction to "see" the structure of the sample. At low temperature they saw regular arrangement of atoms that has slots (like a "sponge", but a regular sponge). In these slots there were more atoms in some fixed positions.

When they increase the temperature, the "sponge" part didn't change, but the atoms in the slots began to move like in a liquid. In the x-ray you get sharp point for the atoms that are essentially still and in a regular arrangement (the points are not the atoms), but the atoms that can move or are in irregular positions don't produce sharp point.

So IIUC in a previous real life experiment other group saw a change. My guess is that the atoms that can move don't drip. They keep trapped inside the "sponge" part (like a small amount of water in a towel). The dripping part is probably a bad metaphor.

\---

In spite we know all the quantum mechanic rules to simulate this, the problem is that the runtime grows exponentially with the number of atoms. So an exact simulation is only possible with only a few small atoms (5-10 Carbons, perhaps 10-20 Hydrogens (but not 10 Carbons and 20 Hydrogens). Potassium has a lot of electrons, so it is more difficult.) (And the simulation is not as exact as a Mathematician would like to call it exact.)

There are some tricks to avoid the exponential time. Like assuming that the atoms/electrons only interact with nearby atoms/electrons. It's quite true, but not 100% true. You can also use some model of how the electrons in one atom interact with the electrons in the other atom. But electrons like to wander, specially inside a conductor, so you must consider the electrons that live between the atoms. It's a lot of fun, there are plenty of model to approximate how the electrons behave in some situation, but each model is good for one situation and bad for other situations.

If you want to go down the rabbit hole [https://en.wikipedia.org/wiki/Density_functional_theory](https://en.wikipedia.org/wiki/Density_functional_theory) , but it is not the only method to try to solve the problem. There are a few rabbit holes, because the exact problem has exponential complexity.

In this work, they use a neural network to approximate the behavior of the electrons in each atom (and between atoms). I guess that they are assuming that they interact almost locally, and hopefully they can get the result in linear time instead of exponential. I'm not sure if this can be classified as DFT or other technique, or they are digging a brand new rabbit hole.

It's difficult to judge the work by reading only a press article, but the abstract of the research paper says:

> _Calculations necessitated the development of an interatomic forcefield > using machine learning, which we show fully reproduces potassium's phase > diagram, including the chain-melted state and 14 known phase transitions._

It looks very promising, specially because in each phase the conditions are different and that makes the use of a single model very difficult.

<comment><USER5> I wrote a computer program which proves this article is wrong.

It avoids exponential runtime by assuming that because newspapers mostly make a mishmash of science articles, that you only need to look at some of the words before deciding whether they made a mishmash of this article. It's not 100% true, but it's quite true.

...

<comment><USER4> Great. When you get it published in a peer review journal, please post it here so we can discuss it.

</comment></comment></comment></comment><comment><USER6> Favorited.

If you were interested in one day creating Star Trek's Replicator, this might be a good place to start. That is, here might be a good place to study the junction between solid and liquid phases of matter (your future Replicator would probably create liquids out of thin air before you figured out how to create solids, and this might be the phenomena you wanted to study to then figure out how to create those solids...)

Also, the list of exotic states of matter in the article is worth reading and re-reading...

<comment><USER7> If you're an amateur of exotic states, try [https://en.wikipedia.org/wiki/Time_crystal](https://en.wikipedia.org/wiki/Time_crystal)

<comment><USER8> It's not an equilibrium state so is different from the others.

</comment></comment></comment><comment><USER9> I recently enjoyed reading Dr. Gerald Pollack's "The Fourth Phase of Water: Beyond Solid, Liquid, and Vapor". I wonder...

[https://www.amazon.com/dp/0962689548/ref=cm_sw_r_cp_awdb_t1_...](https://www.amazon.com/dp/0962689548/ref=cm_sw_r_cp_awdb_t1_HtYLCbAP0ZJDD)

</comment><comment><USER10> Reminds me of the sodium amalgam Nile Red was experimenting with on his last video (other than the April Fools one).

It seemed to be a sponge of liquid mercury dissolving liquid ammonium.

</comment><comment><USER11> Why on earth should we trust (for such things) a model that includes an opaque neural network?

</comment><comment><USER12> Shouldn't plasma be also listed as a state of matter in the opening sentence?

<comment><USER13> They list 6 other states of matter at the end, including plasma.

</comment></comment><comment><USER14> Clickbait title. The discovery is that at high pressures, potassium adopts a complex crystalline structure, of which different parts have different melting temperatures.

<comment><USER15> Ok, we'll use that. If anyone can suggest a better title (i.e. more accurate and neutral, preferably using representative language from the article itself) we can change it again.

<comment><USER4> The melting part is important. It's not just a complex crystal structure. If's a crystal structure with slots that are filled with the same material. The interesting part is that the filling and the main crystal structure have a different fusion temperature.

" _At high pressures, potassium adopts a mix of crystalline and liquid structure_ "???

<comment><USER15> Done. Thanks!

</comment></comment></comment></comment><comment><USER16> Sounds like someone has discovered cats.

<comment><USER15> Please don't do this here.

</comment></comment><comment><USER17> "bizzare" state lol

some day mainstream scientism will realize that it is impossible to extrapolate global reality from local perceptions...

<comment><USER18> Isn't that what science is based upon though? We can only make assumptions based upon observed results. You can extrapolate and then test based upon those extrapolations, and we can acknowledge that there are gaps, but I don't think someone saying "wow, that didn't meet my expectations at all" in any way discredits science.

</comment></comment><comment><USER19> While the material discussed in the article and new, the phase of matter is not new. The term is called non-newtonian fluid. Believe it or not you can make material with these properties in your own home.

An inexpensive, non-toxic example of a non-Newtonian fluid is a suspension of starch (e.g. cornstarch) in water, sometimes called "oobleck", "ooze", or "magic mud" (1 part of water to 1.5–2 parts of corn starch). The name "oobleck" is derived from the Dr. Seuss book Bartholomew and the Oobleck.

Because of its properties, oobleck is often used in demonstrations that exhibit its unusual behavior. A person may walk on a large tub of oobleck without sinking due to its shear thickening properties, as long as the individual moves quickly enough to provide enough force with each step to cause the thickening. Also, if oobleck is placed on a large subwoofer driven at a sufficiently high volume, it will thicken and form standing waves in response to low frequency sound waves from the speaker. If a person were to punch or hit oobleck, it would thicken and act like a solid. After the blow, the oobleck will go back to its thin liquid like state.

<comment><USER20> I wonder if something like that would work in a ballistics armor application?

<comment><USER21> Not ballistic armor but D3O is one material used for impact protection that is flexible but becomes rigid when there's an impact. (I have a ski hat with ribs of this material.)</comment></comment></comment>


XenServer open sourced - <AUTHOR> http://blog.xen.org/index.php/2013/06/25/xenserver-org-and-the-xen-project/

<comment><USER2> This isn't an announcement of future plans; open-source XenCenter 6.2 was released today. This is a pleasant surprise, because I'm actually early in the process of deploying some servers running Xen Cloud Platform (XCP). Now that XenCenter is open source there won't be any more XCP releases, but upgrading from XCP to XenCenter is supported.

This and other questions I had were answered at [http://xenserver.org/discuss- virtualization/q-and-a/categori...](http://xenserver.org/discuss- virtualization/q-and-a/categories/listings/xenserver-org-launch.html)

<comment><USER2> s/XenCenter/XenServer/g

</comment></comment><comment><USER3> If you're interested Intel had a POV to add. [http://communities.intel.com/community/datastack/blog/2013/0...](http://communities.intel.com/community/datastack/blog/2013/06/25/not- your-mothers-open-source)

FD: I work at Intel in the Data Center Group

</comment><comment><USER4> This is pretty big news. I've known some small businesses that have had a need to virtualize, but didn't want to get into everything KVM/OpenVZ, etc entailed. The VMware Essentials bundle (I believe that is what it is called) made decent inroads in this arena, but with everything all the enterprise features being free, I will probably have to start recommending this.

I have been looking into breaking in to a specialized segment of lower-end hosting (VPS, etc) and was looking to base my platform on VMware (rather than OpenVZ/KVM which seems to be the norm) but I am going to take a serious look at this now.

I'm excited to try building the platform around XenServer, and excited to contribute to the project as well -- I hope we see a lot of contributions now that this is open-source. I would love to see a Linux or OS X version of the management client, which is wholly possible now.

I'm installing a test instance of 6.2 now (within ESXi, ironically) to play around with it!

</comment><comment><USER5> You know I always figured that this was just open source to begin with.... I guess I was wrong.

<comment><USER2> Most of the software was already open source, but the pay-for version of XenServer had a few more features than the open source Xen Cloud Platform.

Somewhat to my surprise, Citrix also released the XenCenter management application under an open source license. It would be nice to see a port of that to linux.

[http://wiki.xen.org/wiki/XCP/XenServer_Feature_Matrix](http://wiki.xen.org/wiki/XCP/XenServer_Feature_Matrix)

[https://github.com/xenserver/xenadmin](https://github.com/xenserver/xenadmin)

<comment><USER6> the API , called XAPI, that the management application uses, has always been public and open source, as far as I know. It is based on OCaml, IIRC.

<comment><USER7> > It is based on OCaml, IIRC.

Yes, that's true. They also have some Haskell developers, but they are working on XenClient, not XenServer.

</comment></comment></comment></comment><comment><USER8> Seems like PR move for Intel and Cytrix to bring some interest to technology

<comment><USER9> I am not convinced : this looks like a serious effort and if you take it together with the move of Xen > Linux Foundation, it actually makes sense. Previous attempts to open source bits of XenServer though, do look like PR moves which frankly created a bit of a mess.

</comment></comment><comment><USER10> Nice! The power of competition proven once again.</comment>


CSS for Internationalisation - <AUTHOR> https://www.chenhuijing.com/blog/css-for-i18n/ <comment><USER2> Glad to see vertical writing covered. Wish it covered Ruby styling[0][1] and markup[2] as well.

[0] MDN reference: [https://developer.mozilla.org/en-US/docs/Web/CSS/ruby- positi...](https://developer.mozilla.org/en-US/docs/Web/CSS/ruby-position)

[1] W3C in-depth article: [https://w3c.github.io/i18n-drafts/articles/ruby/styling.en.h...](https://w3c.github.io/i18n-drafts/articles/ruby/styling.en.html#ja_variants)

[2] [https://www.w3.org/International/articles/ruby/markup.en](https://www.w3.org/International/articles/ruby/markup.en)

<comment><USER3> The author covers it in another article (2016): [https://www.chenhuijing.com/blog/html- ruby/#%F0%9F%9A%B2](https://www.chenhuijing.com/blog/html-ruby/#%F0%9F%9A%B2)

<comment><USER2> Thanks for linking! Vertical writing on the web is of huge interest to me.

</comment></comment></comment><comment><USER4> Sorry to be nitpicky, but this is wrong:

> Have you ever wondered how Chrome knows to ask you if you'd like a web > page's content to be translated? No? Okay, maybe it's just me then. But it's > because of the lang attribute on the  element.

The lang attribute is a signal to whatever's inside Chrome that detects language. Here's a simple counter example: [https://twitter.com/chewxy/status/1253076770066010112](https://twitter.com/chewxy/status/1253076770066010112)

The image is an SVG generated by graphviz. With no lang attribute (or even a HTML tag) Still Chrome thinks it's Luxembourgish.

Nonetheless, I appreciate the tip on the pseudoclass for lang.

<comment><USER5> Does Chrome ever _ignore_ the lang attribute?

<comment><USER6> I don't know if it is the case nowadays, but I seem to recall that in the old days they would check and if their model was highly predicting a language different than the one you were claiming they would serve the language they predicted.

Which, even if they don't still do this, I think makes total sense and is what I would do because obviously programmers make mistakes and if your page claims to be English but your language has a high chance of being Armenian and a low chance of being English I would consider it was Armenian.

<comment><USER7> Google crawler apparently ignores "lang" attribute [0]:

> Google uses the visible content of your page to determine its language. We > don't use any code-level language information such as lang attributes, or > the URL.

But what about the Chrome browser?

[0] [https://support.google.com/webmasters/answer/182192?hl=en](https://support.google.com/webmasters/answer/182192?hl=en)

</comment></comment></comment></comment><comment><USER8> I learned a lot from the content in case I need to do more localization/i18n for future.

Nice easter egg, first time seeing emoji used in the url fragment. It also loads a new one.

Edit: _As an idea_ to share, I wonder given the topic, whether different emoji's can be localized too. An emoji can mean something different depending on country.

</comment><comment><USER9> One thing that's been omitted is the :dir() pseudoclass[1] which has been inexplicably ignored by Webkit and Blink. Yeah, it can sort of be replicated by a descendant selector, but it'd be so much more obvious and selfcontained to select an element based on its own calculated text direction; something that's currently only possible in Firefox.

[1] [https://www.w3.org/TR/selectors/#the-dir- pseudo](https://www.w3.org/TR/selectors/#the-dir-pseudo)

</comment><comment><USER10> The article touches on having properties like borders and margins that accommodate the language, but all the examples are manually calculated. I recently saw a talk on Youtube that mentioned that there is (or is coming?) support for margin-start/end kind of syntax that will allow browsers to handle re-orientation of box properties depending on the language. Sadly, can't find it. It was by a pair of people from the Chrome and Edge teams updating on some new features coming. Obviously browser support and awareness will take time to normalize these patterns, but it will help remove the need for many of these manual considerations, which means that support for internationalization should improve in the coming years.

<comment><USER11> I'm confused. The feature you describe is logical properties, which is exactly what the section you're talking about is about. I don't know what you mean by "manually calculated".

<comment><USER10> Indeed! I guess I was confused by the organization of the example[0] for that section. The physical section being first obscures all the examples of the logical block style so all you see is variations of:

      border-top-color: tomato;
      border-right-color: limegreen;
      border-bottom-color: dodgerblue;
      border-left-color: gold;

Looking back, my comment was more due to my own inability to visualize the simplicity of the logical properties as presented vs. what I've seen in other demonstrations and realizing that I lost sight of a resource that I think would be a helpful reference for myself as this new method becomes commonplace.

[0]: [https://codepen.io/huijing/pen/XWmKByZ](https://codepen.io/huijing/pen/XWmKByZ)

</comment></comment></comment><comment><USER12> I was actually expecting to see i18n translations with lang. Something like:

      .i18n-hello:lang(:en) {
        content: "Hello";
      }

      .i18n-hello:lang(:nl) {
        content: "Hallo";
        }

      hello label

That doesn't work, so you'd have to use ::after, but that requires some more verbose styling.

<comment><USER13> But this mixes content and style, so would be difficult to update (for non technical users etc.). Besides, it's fairly bad practice and won't scale to sentences well.

</comment></comment><comment><USER14> > Have you ever wondered how Chrome knows to ask you if you'd like a web > page's content to be translated?

How difficult is it to automatically detect the language? Probably naive but how far can you get by counting how many common words on the page are from a particular language (e.g. "the of then because I" for English and "je pour des les" for French)?

<comment><USER15> Google translate already has an auto-detect language feature.

I suspect it would be reasonably simple to add a "Translate this" button somewhere in Chrome (perhaps it's already there, I don't have Chrome installed on this machine.)

Perhaps automatically doing it for every site would be a little bit intrusive on the privacy front.

<comment><USER14> > Google translate already has an auto-detect language feature.

Yep, I'm asking how hard it is to build a quick and simple auto-detect feature. Is it harder than it looks?

<comment><USER15> It kind of depends what you mean by build. From scratch - I have no idea. For Google Chrome? It's just an API call away - [https://cloud.google.com/translate/docs/basic/detecting- lang...](https://cloud.google.com/translate/docs/basic/detecting-language)

</comment></comment></comment></comment><comment><USER16> I just wish CSS offered a simple way to fix the aspect ratio of an arbitrary element.

<comment> frosted-flakes That's coming! It's not implemented in any browsers yet, but it should be soon. It was introduced in "CSS Intrinsic & Extrinsic Sizing Module Level 4".

It will use the property "aspect-ratio" with values like "16/9" or "1/1".

MDN: [https://developer.mozilla.org/en-US/docs/Web/CSS/aspect- rati...](https://developer.mozilla.org/en-US/docs/Web/CSS/aspect-ratio)

Article about it by Rachel Andrew in Smashing Magazine: [https://www.smashingmagazine.com/2019/03/aspect-ratio- unit-c...](https://www.smashingmagazine.com/2019/03/aspect-ratio-unit-css/)

<comment><USER17> You can set the width and height attribute (HTML attribute, not CSS property) today.

Recent Chrome and Firefox use that to determine aspect ratio for jank-free loading.

<comment> frosted-flakes For images and iframes, but I don't think that works for any element. In any case, hardcoding that kind of information in the HTML is not ideal.

</comment></comment></comment></comment><comment><USER18> Very good writing, and very informative. I especially enjoyed the gif of traditional vs. simplified Han.

</comment><comment><USER8> In modern browsers, whether or not lang is provided, the browser is smart enough to set the correct encoding / glyphs.

In the olden times, browser was not smart (ie: still set the wrong charset). You may have come across for example, an asian site (japanese, korean, chinese), and see a lot of text with "?"'s and "□"'s like so ??? □□□ in 90's and common still through beginning 2000's. Glad these days you don't have to spend time trying to match it up, but it was available readily in browser's menu for you to match.

I think here, the lang tag is useful so you can explicitly tell the browser. And if you are designing the page, you have more control for localization to target by the international code.

<comment><USER19> I think you are confusing language (English, French, Arabic, etc) with encoding (ASCII, UTF-8, UTF-16, Latin1, etc).

You do sometimes see mojibake in web pages, (question marks and □□ in place of the real text). These are caused by incorrect encodings. The web server tells the browser which encoding to use using the HTTP header Content-Type or using the <meta charset="UTF-8"> HTML element. You should always set the encoding rather relying on the browser guessing.

<comment><USER8> I was referencing asian languages as one set of examples for encoding. Of course setting the encoding is important (whether html or within a program dealing with strings - I had my share of hard bugs only to realize just that, another story)!

Here I was just sharing my encounters of the browser rendering ?? and □□ character marks, because it did not know. The browser had a "Auto Detect" charset mode, so one always had to toggle (and remember to revert back again when viewing another page). For the very reason you have indicated, "should always set", but in those days (and maybe even today), not always set.

Again, just a memory sharing.</comment></comment></comment>


Mozilla is giving up on their IRC server - <AUTHOR> http://exple.tive.org/blarg/2019/04/26/synchronous-text/?s <comment><USER2> As an admin helping out the Go Slack workspace, which is about to cross 39,500 registered users, they would be ill-advised to go with Slack if moderation is one of their goals. Full disclosure: our Workspakce does have some sort of agreement with Slack, so our space isn't a free space (we have full history), and even then we aren't able to get them to provide support around moderation of users.

There is no mechanism to ignore a user, mute a user, or temporarily suspend a user if they need a timeout. The first two are completely impossible, while the latter today is manual / mostly possible using undocumented APIs and mechanizing of HTTP requests. Users reporting spam is done by them sending a message to an admin, or in the admin channel, and requires someone to manually intervene and moderate the message. So we effectively need to aim for follow- the-sun moderator coverage, which is a bit painful.

In terms of usability and accessibility, some of the things Slack does (e.g., threads) are not super-inclusive or accessible to users who use screen readers. Today, based on feedback I've gotten, IRC is still superior for users who rely on screen readers due to some form of visual impairment.

Whichever product they go with, it'd be nice if they provided an authenticated IRC gateway which would allow this class of user to have a better experience using the platform as they could use one of the text-based IRC clients that has served them well.

For everyone who is saying they hope Slack isn't the choice, I'm fairly confident with these issues today they won't pursue Slack. If anyone from Mozilla, or any other org, would like to discuss some of the challenges we've had using Slack as an open community I'm more than happy to schedule time. I'd like to help you provide the best experience and community for your users.

<comment><USER3> Have you tried Discord? I seems like it would meet all these desires. We switched to it a year ago and it's been great.

<comment><USER4> Discord has aggressive security measures. I can't use it, because it won't let me access it from my desktop unless I give it a phone number. I guess it's decided I look like a headless browser or something.

Certainly I'd say discord is a poor fit for an organization allegedly dedicated to web freedoms, such as mozilla.

I'd suggest rocketchat or mattermost, personally. Well, to be honest I'd suggest IRC, but if that must be abandoned, rocketchat is pretty good.

</comment></comment></comment><comment><USER5> _> We are not rolling our own. Whether we host it ourselves or pay for a service, we're getting something off the shelf that best meets our needs._

I sincerely hope it's not Slack and some restricted search archive platform. Moving away from IRC to a newer system could provide long lived archives to users. But if privacy is very important, then a "no archive" option would be fine (similar to IRC). Anything in between, like "search the last 10000 messages", would be a disaster for active channels with many members.

 _> It needs to be accessible to the greater Mozilla community. We are evaluating products, not protocols._

I'm sure whichever the chosen product is, it's going to be based on HTTP to allow "schools, colleges or corporate networks" to be able to connect. It seems weird that we're dumping everything on to HTTPS, and one day in the future there would be a world where only port 443 would be open and all the mess, and the holiness, would flow through it, and it alone. In the name of securing networks, we seem to have gone to an illusion of security by moving to one port for almost all communications.

 _> We aren't picking an outlier; whatever stack we choose needs to be a modern, proven service that seems to have a solid provenance and a good life ahead of it. We're not moving from one idiosyncratic outlier stack to another idiosyncratic outlier stack._

I still hope it doesn't come down to Slack or Hipchat or some commercial offering. Maybe host a Matrix instance? Or Mattermost? Or Rocket.chat?

<comment><USER6> Matrix shows how thorough the switch to HTTP has become. Like with DoH, what makes Matrix most attractive is the ability to implement solutions using pre- existing web application stacks, like Node.js. It's a sort of path dependency where the easiest way to implement a simple solution starts with a very complex, mostly superfluous foundation.

The fact that port 80 and 443 are less likely to be blocked is a distant, secondary factor. Frankly, I've never been on a network that blocked other outbound ports. And I've definitely never seen a network where hosted services could only ever receive traffic on port 80 or 443. Rather, I think it's _more_ (if not entirely) a matter of people justifying the use of web stacks to implement services which cry out for simpler solutions.

<comment><USER7> > Frankly, I've never been on a network that blocked other outbound ports.

That's just down to who you've worked for. I've worked for two companies, both well-known brands, both operating in the consumer space (nothing secret/shady), where most outbound ports were blocked.

In one case it certainly was possible to get them unblocked for access to specific hosts or endpoints but you'd have to go through an approval process that took about a week. I never had a request refused but it certainly could slow progress, although I got into the habit of trying to get all of us to anticipate what we might need and front-load such requests.

<comment><USER8> At one time in a past life, I was running SSH on port 80, then using a SOCKS proxy to escape the madness of the network I was on.

</comment></comment></comment></comment><comment><USER9> As an IRC user since the early 90s (EFnet and freenode), I can say that it really feels like it is dying. There are still a few popular channels with helpful people, but the vast majority of channels are silent with no one but afk users logged into a seemingly forgotten 'screen' session. And of the channels that do have real people, those people often seem to be there for no reason other than to tell people to RTFM, play topic nazi to such an extreme level that apparently nothing is actually on topic, or just generally berate people for having the gall to say something in the channel. Ops are extremely touchy and seem willing to immediately kick people rather than have actual discussions about things that challenge any of their beliefs about a particular topic or how the channel is being run (any such challenge, no matter how genially presented, is perceived as combative and results in a swift kick).

The heyday has past. People moved on, had families and other responsibilities, with no time to sit idly chatting anymore. The newer generations are on various messenger apps, Slack, or Discord.

Though The Lounge looks pretty nice.

<comment><USER10> >those people often seem to be there for no reason other than to tell people to RTFM, play topic nazi to such an extreme level that apparently nothing is actually on topic, or just generally berate people for having the gall to say something in the channel. Ops are extremely touchy and seem willing to immediately kick people rather than have actual discussions about things that challenge any of their beliefs about a particular topic or how the channel is being run (any such challenge, no matter how genially presented, is perceived as combative and results in a swift kick).

Funny, it's been my experience that IRC culture was always like this, especially in the late 90s when I started using it.

<comment><USER11> Came to say the same, I can hardly remember participating in a constructive conversation over IRC within the last 10-15 years. Not saying they don't happen, just my experience has been the same as the parent posters.

<comment><USER12> Depends on the channel, Mozilla's IRC has channels (like #deeplearning) with helpful people ready to hold your hand through using and extending Mozilla TTS & Mozilla DeepSpeech.

</comment></comment></comment></comment><comment><USER13> I never see addressed the biggest reason (according to me) why IRC loses, so let's spell it out.

IRC isn't persistent (i.e. you can't read messages delivered while you were offline) unless you setup an IRC shell. This is technically difficult (much more so than dicking with nickservs and so, which is already a pain point). Hosting it is also not __free __. Count 5$ /month on CloudOcean or some such.

[https://www.irccloud.com/](https://www.irccloud.com/) is a great service that alleviates the pain, but now you're paying 5$/month and you just have IRC — you can't run other services on your server.

If you value 5$ or your time more than the idea of "fighting for freedom by using IRC", you just don't use IRC unless you're forced to. This is not unreasonable, so many people do that, and consequently, communities miss out on these people.

You want to save IRC? Make a free (as in free beer) clone of IRCCloud. Easy.

<comment><USER14> Once all the chat systems without persistence have disappeared, some new hip company will come along touting "no persistence" as a feature, maybe even a privacy feature.

But seriously, I don't understand why persistence is such a huge deal to people. Chat is for transient chat - it is meant to be non-persistent just like verbal communication.

There are so many mechanisms for persistent messaging (forums, text messages, emaills, and everything in between), I don't understand how an entire industry spawned from a concept we already had?

<comment><USER15> I know I hate it when I join IRC channels and have no context as to what anybody has been talking about, as there is no history to quickly go over. Even just having the past days history would help in this regard, at least for more active channels.

It's the same as just barging into a conversation a group of people are having. You don't want to just join and start talking about a completely different topic. So you join, and wait for a bit to get a feel for what they're talking about before piping in. But with IRC, sometimes it can take _days_ to get that amount of information, depending on how active the channel is. The same thing could easily be accomplished by being able to read the last 10 messages in the channel.

<comment><USER16> On snoonet at least there is a channel option frequently used, that makes the channel send the last x messages to the recently joined user.

It exists.

<comment><USER17> What ircd are they using?

<comment><USER18> InspIRCd according to this: [https://ircv3.net/support/networks.html](https://ircv3.net/support/networks.html)

</comment></comment></comment></comment></comment></comment><comment><USER19> It's a shame that IRC usage is dwindling especially in techie circles. However I can understand it if it doesn't work for them any more although in my opinion IRC has a lot of moderation tools available. In any case, the "problem", of sorts, is not abandoning IRC but what comes next. The web is choke full of proprietary communication protocols that cannot talk to each other and you have private entities acting as gateways to online communication. Instead on relying on protocols and let clients decide how they connect to the network you have users being herded into walled "communication" gardens. This goes beyond Slack or Discord or chat-app-of-the-month. Having a flagship open-source project behind a proprietary platform for communicating with the users and developers can't help but leave a sour taste in the mouth.

Well, at least there is still Matrix to hope for.

<comment><USER20> A slack like interface can be built on top of IRC. I'm a bit amazed that no one has decided to do that.

<comment><USER21> check out irccloud

<comment><USER17> I am permanently banned from an IRC channel because I connected to it from IRCCloud.

<comment><USER22> What was the reasoning?

<comment><USER17> Haven't been able to confirm it, but I believe it's because IRCCloud stores logs in plaintext.

<comment><USER22> Interesting, thanks for the response!

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> I use IRC quite heavily. Especially for cryptocurrencies and local hackerspace channels. They're all very active.

But I agree with the post, "irc is not fine", and never was fine if you want to communicate with "regular" people.

It doesn't have spam filters, easy GUI or easy registration process. You could build all of those on top of IRC, and I'm sure that some people did, but there's no "standard" and most people just can't be bothered.

As the post said, often "IRC traffic isn't allowed past institutional firewalls".

Besides, when was there a time in the history of the internet that irc was used to communicate with laypersons? If that's Mozilla's goal, they're right to switch.

That said, irc is fine, or even the best, for some communities. Especially communities of internet-savvy people.

It's decentralized, open, easy to access and inclusive. Such communities rarely meet the need for spam filters, and each of their members possess a well-distilled taste for personalized tools for irc.

That's why cryptocurrencies or hackerspaces channles are great on irc. That's why #rust channel is fantastic.

I still didn't find any modern substitution as good as irc for those communities. And yes Matrix, I'm looking at you! You're just not there yet.

<comment><USER24> >But I agree with the post, "irc is not fine", and never was fine if you want to communicate with "regular" people.

That's cool. I don't want to communicate with regular people, I want to communicate with hackers. If I wanted to communicate with regular people I would use Twitter.

<comment><USER25> And you're not Mozilla (which does want to communicate with laypeople) so...

<comment><USER24> If they wanted to communicate with laypeople they'd offer support over the channels laypeople expect support nowadays, namely Facebook. Instead they are going to choose some middle ground that will displease everybody; they will botch it, as they like to do.

They are already working on botching it, since they've moved the Rust channel to a closed source alternative with no expectations of privacy: [https://blog.rust-lang.org/2019/04/26/Mozilla-IRC-Sunset- and...](https://blog.rust-lang.org/2019/04/26/Mozilla-IRC-Sunset-and-the-Rust- Channel.html)

<comment><USER26> Mozilla did not move the Rust channels. We did.

<comment><USER23> Are there really no good open source forum alternatives?

\-- asking for a friend :-)

<comment><USER26> We already use an open source forum: discourse.

If you mean real-time chat, in my personal opinion, Discord is the best choice. Zulip is good, if you can deal with it being a bit weird. The other options are fine, but not great. You may have different opinions than me personally.

<comment><USER27> You mean the same Discord that's now majority-owned by Tencent, right?

<comment><USER26> I don't know anything about their ownership, but I also don't think you're actually asking that question.

<comment><USER27> Sure, it may be a bad-faith question, but I think the point still stands. IRC, as an open communications protocol, will always, always, always be better than private companies with the potential to be controlled by anything. Richard Stallman would be rolling in his grave.

<comment><USER28> Christ, you scared me there. Stallman is not dead.

<comment><USER27> He's pretty old, I was making a statement about the future. Bit sloppy nevertheless.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> I know there were/are a few blind people working on Mozilla's stuff and the move to anything that is not open source will make it much harder for them. There was a person[1] who had done significant work on the Rust compiler and said that he would have a much harder time doing it now, since the move to Discord and that he might not be able to participate in the community after the switch[2]. Proprietary solutions are a little bit better for the 80% of people, but way worse and/or unusable for the 1 to 5 percent, depending on how techy the community is. We have to realize that those solutions have big gains, but they also have huge tradeoffs. IRC inconveniences some people. Discord excludes some completely.

[1] [http://camlorn.net/posts/April%202017/rust-struct-field- reor...](http://camlorn.net/posts/April%202017/rust-struct-field- reordering.html) [2] This thread [https://twitter.com/camlorn38/status/1121879891035602945](https://twitter.com/camlorn38/status/1121879891035602945)

<comment><USER30> It's really frustrating to me how inaccessible Discord is. At its heart, Discord is text and voice chat, which you would think would be the easiest forms of communication to make accessible.

Due to a genetic condition I have that predisposes me to blindness I have preemptively installed NVDA on Windows and Orca on Linux, and the inability of either of these tools to deal with Discord the last time I tried is shameful.

</comment></comment><comment><USER31> Only Matrix would make sense.

Here's something worth paying for if they don't want to selfhost:

[https://www.modular.im/](https://www.modular.im/)

[https://medium.com/@RiotChat/introducing-modular-awesome- hos...](https://medium.com/@RiotChat/introducing-modular-awesome-hosting-for- riot-matrix-665a7a0c616)

</comment><comment><USER32> I just want to say, for all it's worth, that the #rust channel on MozNet has been by far one of the most healthy and productive IRC channels that I've participated in. The channel is always active, and there is a constant presence of extremely qualified and patient folks in the chat (and often Rust core members as well). I hope that whatever they switch to will be able to foster a community as open and welcoming as their IRC.

<comment><USER33> Rust's post about this: [https://news.ycombinator.com/item?id=19761836](https://news.ycombinator.com/item?id=19761836)

</comment></comment><comment><USER34> I don't understand what moving to slack is going to give them, which is inevitably where this is going to lead (or a similar web-based chat).

IRC has the same tools for banning users as Slack, if not more powerful as you can ban ranges etc. You can require people to register with an email in the same way slack does, although I'd argue being anonymous and being able to talk without an account is one of IRC's best features.

I can't say I ever went on Mozilla's IRC, but I have spent almost 20 years on other IRCd's. Seeing it be replaced, just to be able to use rich messaging breaks my heart.

<comment><USER35> IRC isn't really anonymous or private. Your IP address is visible to everyone by default.

<comment><USER34> Which is incredibly easily to get around with a bouncer and shell company in eastern europe or pretty much anywhere. We're not talking state-actor anonymous, but anonymous enough.

</comment></comment></comment><comment><USER36> Matrix and Riot is good open source replacements for IRC. With Matrix and Riot you get a modern interface yet can bridge out to IRC open source networks and channels!

Here is links to Matrix and Riot. [https://matrix.org/blog/index](https://matrix.org/blog/index) [https://about.riot.im/](https://about.riot.im/)

Please support open source projects! The Internet was built on open standards.

</comment><comment><USER37> I had a question for the Firefox UX team a few months ago and went to #ux on irc.mozilla.org. The channel was completely dead. Someone that wasn't from the UX team was still there and told me they all moved to a private Slack channel.

<comment><USER38> > Someone that wasn't from the UX team was still there and told me they all > moved to a private Slack channel.

So private channel _and_ closed platform.

Excellent discoverability and excellent UX, eh?

</comment></comment><comment><USER39> Irc unauthenticated? IRC has supported auth services since what 1995? There are also plenty of web irc gateways so I don't understand the reasoning to move to something more complicated for little gain, want history? Run ii in a tmux session and tail to a file, want to post images with a fancy GUI taking a gig or so of ram use slack.

<comment><USER40> They apparently want anyone to be able to easily connect and talk to developers, except for trolls, scammers, spammers etc. I'm not really sure what kind of authentication provides that, but they seem to have something in mind.

<comment><USER41> Perhaps something like being able to browse and search without registering, but if you want to chat you need to create an account?

<comment><USER42> So basically muting all unregistered users by default. Something IRC can do.

</comment></comment></comment></comment><comment><USER43> When I worked at Mozilla, "talking to a room full of bouncers" was a common joke on my team. In a fully distributed team (we were spread out across the northern hemisphere) this is a terrible way to work. You don't know who is online or whether you can contact them. There's no guarantee they'll get your message if you send them something urgent. Everything that's not "typing text in real time" is harder and worse (search, sharing files, sending long messages, mobile support, etc.) and everyone has to scrounge for their own tools to work around these insufficiencies. In a work environment, using a tool that only does part of what you need it to do is a crazy irresponsible use of resources.

IRC might be useful in some circumstances, but supporting team communication—especially for remote teams—is not one of those circumstances.

<comment><USER44> > You don't know who is online or whether you can contact them.

I've actually had this problem with most, if not all, IM/chat systems I've had to use for serious work. They have better UX _design_ for indicating availability, but I can't think of one where it's consistently worked the way I expect it to. Some explicitly allow people to fake/hardcode their status; others have some mixture of caching/update issues and strange criteria for deciding whether a user is "active" or "present" such that the indicator isn't very reliable in practice.

<comment><USER43> > Some explicitly allow people to fake/hardcode their status

That's not an issue with the tech, it's an issue with the people. I'm not shooting off messages with no idea of whether they'll arrive, I'm at least trusting the person's intended availability. If they're just being an ass and marking themselves as perpetually unavailable, that's an issue I'd take up with their manager.

In my experience, modern systems like slack and discord (and even hipchat) work well enough with their availability indicators. Chat apps five years ago I would not trust as much.

</comment></comment></comment><comment><USER45> Please, Mozilla, choose Matrix. [https://www.ruma.io/docs/matrix/why/](https://www.ruma.io/docs/matrix/why/)

</comment><comment><USER46> If I'm reading this correctly, the main problems they have with IRC is that it's too "old"/obscure, and too open — simultaneously too difficult and too easy to access. Hard to control who gets in and what they say.

I haven't seen much spam or harassment on IRC, but I haven't been to Mozilla's server.

As for newbie accessibility, doesn't a web gateway solve that? You could change the font family from monospace to Lato and it's instantly 20 years more modern :)

<comment><USER46> > And when we're talking about blind spots and invisible social access > controls, of course, what we're really talking about is privilege. "Working > in the open", in a world where computation was scarce and expensive, meant > working in front of an audience that was lucky enough to go to university or > college, whose parents could afford a computer at home, who lived somewhere > with broadband or had one of the few jobs whose company opened low-numbered > ports to the outside world; what it didn't mean was doxxing, cyberstalking, > botnets, gamergaters, weaponized social media tooling, carrier-grade > targeted-harassment-as-a-service and state-actor psy-op/disinformation > campaigns rolling by like bad weather. The relentless, grinding day-to-day > malfeasance that's the background noise of this grudgefuck of a zeitgeist > we're all stewing in just didn't inform that worldview, because it didn't > exist.

[http://exple.tive.org/blarg/2018/11/09/the-evolution-of- open...](http://exple.tive.org/blarg/2018/11/09/the-evolution-of-open/)

<comment><USER47> Given ... everything ... about the internet, do you ever think we're at the "throw one away" point of the dev cycle?

<comment><USER46> I'd like to take your argument and apply it to the human species. In both cases, I think the good outweighs the bad.

</comment></comment></comment></comment><comment><USER48> That's too bad.

Personally I dislike this trend towards a plurality of chat "services" and "apps." Now each project I interact with has their own chat service. I have to maintain accounts on all of them and install several applications to interact with each. It's a pain to manage.

Not to mention that most of these services use Electron-based chat clients which exclude a bunch of people who cannot afford the kinds of machines required to use them or they have to suffer a poor experience on lower-end hardware. It also excludes people who use accessibility software or automation that doesn't integrate with web-based clients.

The user experience on IRC scales better. Anyone can write a rich, easy-to-use client or server. If you happen to be a programmer you can write your own tools to manage your own user experience. The drift from casual user to power user isn't stopped by a walled garden of a tightly-controlled user experience that doesn't integrate with anything.

</comment><comment><USER49> I don't really understand how switching to a different system is going to do anything about levels of abuse and harassment.

I'm sure it will be easier to use, at least. IRCv3 was trying to solve some of this but I haven't heard a peep in years.

<comment><USER50> Spam can be difficult to stop on IRC compared to modern webchat applications. From lacking things like javascript, captchas, cdns, and so on, to having a distributed network architecture and fewer ways to verify users.

<comment><USER51> > having a distributed network architecture and fewer ways to verify users

You have exactly as many ways to verify users as are implemented in your NickServ, and pretty much every snazzy web-y proprietary chat platform has a "distributed network architecture" as well.

IRC has plenty of real problems, but your particular list of arguments seems completely irrelevant.

<comment><USER52> NickServ is not typically required for IRC usage.

<comment><USER53> If your network is large enough to have spam and identity issues, you have nickserv.

</comment></comment></comment></comment></comment><comment><USER54> Discord is blocked in China, and a large number of people in China are not willing to use VPNs.

Discord uses themes that do not meet minimum contrast guidelines (#747F8D on #FFFFFF is 4.06:1, failing WCAG AA for normal text).

Discord says third-party clients[1] and even client-side CSS modifications violate their ToS [https://twitter.com/discordapp/status/983359562458849280](https://twitter.com/discordapp/status/983359562458849280)

[1] [https://old.reddit.com/r/discordapp/comments/8tukek/ripcord_...](https://old.reddit.com/r/discordapp/comments/8tukek/ripcord_unofficial_native_discord_client_no/e1adbu5/)

</comment><comment><USER55> There's really a need for IM interop. These fragmented islands stall the network effect (Metcalfe's law) that is needed to sustain and grow communities.

I guess the best thing for the current situatio would be a headless service that would connect to your IM identities, and buffer messages, from many different IM identities and protocols. You would then have intermittedly connected web or terminal or mobile apps as its clients. Does something like this exist?

<comment><USER56> sounds like matrix.org

<comment><USER55> I think bridges are not a good enough level of integration. You really need to have your personal connection to your IRC servers.

(Unless the matrix IRC bridge connects to the IRC server with a server-to- server type connection and can thus address messages from/to virtual users on the IRC protocol level. But that would need a lot of coordination and authorizations from IRC server administrators, which brings in so much friction that it probably kills the idea.)

edit: it seems possible that the matrix irc bridge will make a new client irc connection per bridged user, which sounds like a better idea. hard to make out from the docs though.

<comment><USER56> This is precisely what happens. The matrix.org bridge has approximately 25k open client connections to freenode. It would probably be a good idea to switch it to server-server connections to save resources, but afaict nobody has experimented with that yet. If you've ever seen users with an [m] at the end of their names, that's the default name for bridged matrix users.

</comment></comment></comment></comment><comment><USER57> Freenode works for other open source projects. Mozilla might even be able to direct a little resources and governance influence their way. (If Freenode didn't work out, it was worth a try, and an easy move from irc.mozilla.org.)

<comment><USER58> Rust has unofficial channel on Freenode, and it's mentioned in Rust team announcement for moving away from IRC: [https://blog.rust- lang.org/2019/04/26/Mozilla-IRC-Sunset-and...](https://blog.rust- lang.org/2019/04/26/Mozilla-IRC-Sunset-and-the-Rust-Channel.html)

I am sure other products/teams have channels there too, they just won't be official go-to place to chat.

</comment></comment><comment><USER59> Reading the comments, it amuses me that those who support Linux fail to realize that IRC is the microkernel (i.e. Minix) approach in messaging. Want authentication/security/archiving/etc.? Layer things of variable quality on top, and hope there aren't any holes on them!

</comment><comment><USER60> This is a good watershed moment for FOSS as a whole and I hope Mozilla decide to fork Mattermost or something similar and expand it to suit their needs over using Slack if that's the direction they head.

Something federated and encrypted like Matrix/Riot would be fun. Having something that's federated would be lovely to see other members of the FOSS community start to come together over time.

but there is a lot of problems with those rich text/react/Electron thick apps can be "painful" tho

</comment><comment><USER61> As you are considering multiple alternative stacks, may I suggest Mattermost? Runs decently across all major client OSes, supports Slack-style hooks and thanks to multi-team capability can also be used to further the development of other OSS projects.

</comment><comment><USER62> > We are evaluating products, not protocols.

So _not_ using the open internet protocols Mozilla claims to champion.

What a disappointment.

<comment><USER63> It is! This is one of the things where they can be principled instead of pragmatic because their browser share will not diminish due to this decision (unlike the inclusion of DRM).

</comment></comment><comment><USER64> The danger of giving up on IRC and going with a hosted corporate product is the chilling effects on free speech by being at the whims and mercurial mercy of corporate interests. They ought to stay with a self-hosted product that cannot be shutdown by whichever government or corporation decides to ban or restrict speech, thereby ceding what should've been public commons to being under the thumb of a particular government or corporation, and what they deem acceptable, not the community/community leaders deciding. I suggest hosting it somewhere like Iceland.

</comment><comment><USER65> Mozilla's talk:

> Our mission is to ensure the Internet is a global public resource, open and > accessible to all. An Internet that truly puts people first, where > individuals can shape their own experience and are empowered, safe and > independent.

Mozilla's walk:

Fuck it, spin up a Slack room.

<comment><USER66> You could levy this complaint if they actually end up picking Slack (or something similarly proprietary like Discord), but that seems quite premature. I'll miss moznet as much as anyone, but there's no denying that IRC has been left in the dust this past decade or more.

<comment><AUTHOR> It seems that by left in the dust, you mean "remained lightweight and simple". The popular alternatives so far don't seem to have any clients I find pleasant to use, and are rather strongly discouraging anyone from writing third party clients.

<comment><USER67> No, by left in the dust they mean plummeting usage numbers.

It seems your priorities are not well aligned with those of the majority of users...

<comment><USER39> If the majority of users cannot figure out how to type /nickserv register do you really want to talk to them? Consider it a filter

<comment><USER68> This elitism is a big part of why younger users* such as myself have never gotten much use/utility from IRC and hence exacerbates its growing irrelevance compared to alternative tools.

*Think XMPP GTalk etc. which were IMO superior in many ways to Slack or MS Teams

<comment><USER39> I'm not trying to be elitist, but if someone won't put a little effort into joining a conversation how will they ask questions or report issues?

</comment></comment></comment></comment></comment></comment></comment><comment><USER69> Please Mozilla! Use an open alternative like Matrix/Riot or even better - BUILD one of your own if you think Matrix doesn't cut it. A foundational OSS company depending on a closed source product and closed protocol for such a fundamental need such as communication is simply wrong.

</comment><comment><USER70> Off of the main topic, but this blog is basically unreadable to my form of colour-blindness. The link colour is unreadable against the page background, and the right nav is so low in contrast I can't read any of it without using text selection to artificially improve the contrast.

</comment><comment><USER71> Looks like I am too late to this party. I just recently started visiting the mozilla ircd. There are lots of channels and very little way of navigating around. I was trying to figure out who to talk to about network support or if such a channel existed and no one had an answer. People come in asking support questions but no one has an idea of which channels to best ask in. #firefox, #introduction and #newbie are 3 channels doing the same thing and the questions just get split off. If they can't maintain their ircd, maybe just register a project on freenode who seems to be able to handle roughly 80k people just fine.

Edit: Just checked, freenode has a #firefox, not sure how official or how maintained it is.

</comment><comment><USER72> Please use Matrix. Please.

</comment><comment><USER73> Many things mention about other services are still possible with IRC; in some cases by the client side and in some cases by the server side. Server side logging is possible (and I have implemented this once) with IRC. Still, you can make it available with multiple protocols, and you can alter an implementation of a IRC server even if you do not have it available with other protocols too. IRC is also easy to use without any special software.

I currently have a NNTP server set up, but not IRC or any other kind of chat system (but if I do set one up, it will almost certainly be IRC).

</comment><comment><USER74> Are Riot and Matrix compatible with irc clients? If so, wouldn't that mostly solve the problem? You have a way to phase out legacy clients and time to work the kinks out of an open solution.

</comment><comment><USER75> I hope they move on to using Matrix. I think the successor to IRC ought to be not slack or any other closed source chat app but an open source one.

</comment><comment><USER76> Mozilla could be interested in the greatest new chat product from the getstream.io folks. It looks like not an outlier, being used by PH, unsplash, and other great websites.

Maybe worth checking out!

[https://getstream.io/chat/](https://getstream.io/chat/)

</comment><comment><USER77> I'm more than a little surprised nobody has chimed in advocating Openfire, which is Apache 2.0, standards based (XMPP et. al.), extensible, and also has some pretty nice browser clients out there (e.g. conversejs).

<comment> j--r There are way better XMPP Servers now ;)

</comment></comment><comment><USER78> Whatever happened to XMPP?

</comment><comment><USER79> > We've come to the conclusion that for all IRC's utility, it's irresponsible > of us to ask our people – employees, volunteers, partners or anyone else – > to work in an environment that we can't make sure is healthy, safe and > productive.

I don't know about healthy or productive, but I am fairly certain that IRC is safe.

What worries me is that 'safe' has become a bit of a euphemism to mean 'unchallenging,' and what this really means is that the organisation which booted Brendan Eich really wants to unperson anyone who blasphemes this week's orthodoxies.

<comment><USER80> > 'safe' has become a bit of a euphemism to mean 'unchallenging

I doubt the concerns are about people discussing Rust vs C++. And, this being Mozilla's semi-internal technical discussions, even the most intellectual, data-backed hot takes on the culture wars de jour are probably out of place: getting DMs like "here are twenty proven statistics girls are bad at math" because you happen to use a female handle is still harassment, even if (hypothetically) true.

</comment></comment><comment><USER24> I sometimes feel bad about Mozilla dying, then I see all the stupid stuff they do and I realise it serves them right.

</comment><comment><USER81> What are they replacing it with?

<comment><USER82> It's right there in the blog post:

> Very soon, I'll be setting up the evaluation process for a couple of > candidate replacement stacks

They don't know yet.

</comment></comment><comment><USER83> Users seem to have given up on Mozilla a long time ago.

<comment><USER84> You're not wrong, even if it is an unpopular opinion. It's really sad to me as an early internet user. Their side projects have all seemed to fail, and Firefox has never been further behind. I don't see them as being solvent in as little as a few years.

<comment><USER85> That's too harsh IMO. FF is working absolutely great on my desktops, phone, and as dev browser. And Rust seems extremely popular with a vocal minority on HN at least. But yeah, I'm concerned as well - Mozilla should focus on producing a good browser rather than pouring energy into side projects such as Rust and especially WASM which do not contribute to that goal.

<comment><USER84> I want to believe that, and even tried to go all Firefox for the previous two weeks. I will say they have good Sync, which nobody outside of Chrome had achieved at all. The desktop browser is mostly OK, no real complaints. On mobile, however, Firefox is noticeably slower than any of the usual blink based browsers, and most importantly to me, uses way more battery life. I love PL things and am glad Rust exists, but from the outside it feels like a wasted effort, for now.

<comment><USER86> Keep an eye out for improvements on mobile.

[https://www.androidpolice.com/2019/04/26/mozilla-outlines- pl...](https://www.androidpolice.com/2019/04/26/mozilla-outlines-plan-to- replace-firefox-for-android-with-fenix/)

<comment><USER87> [https://github.com/mozilla- mobile/fenix/pull/1707](https://github.com/mozilla-mobile/fenix/pull/1707)

I will wait for Fennec...</comment></comment></comment></comment></comment></comment>


IOS7 Bug Lets Anyone Bypass iPhone's Lockscreen To Hijack Photos,Email,Twitter - <AUTHOR> http://www.forbes.com/sites/andygreenberg/2013/09/19/ios-7-bug-lets-anyone-bypass-iphones-lockscreen-to-hijack-photos-email-or-twitter/?utm_campaign=techtwittersf&utm_source=twitter&utm_medium=social

<comment><USER2> Err, this is from Sept of last year and was fixed. What's this doing here?</comment>


Tesla shares fall after Consumer Reports says it will no longer recommend Model3 - <AUTHOR> https://www.cnbc.com/2019/02/21/tesla-tanks-subaru-soars-in-consumer-reports-new-reliability-survey.html <comment><USER2> Umm, I'm seeing +$15/5%. Oh, I see, the article is a week old.

</comment><comment><USER3> 300$ seems to be a magic threshold for the Tesla stock price. I have been watching this for a while and each time there are any major news the price rises or falls it will eventually go back slightly above 300$. Really interesting.

</comment><comment><USER4> I want Tesla to succeed. But they are up against some huge challenges right now. Hoping they can overcome, and continue shipping awesome and reliable products.

<comment><USER5> I hope they succeed simply because if they fail, it will be a signal to car manufacturers that EVs aren't viable in the market, and other car makers will deprioritize or even cancel plans for an EV.

As it is, other car manufacturers that make EVs tend to greatly miss the mark. They either have range that is too short (Nissan Leaf), are ugly as sin (Which I admit is subjective, but BMW i3 and the upcoming Volvo Polestar 2), or have unimpressive performance (Nearly all EVs that aren't Tesla).

What Tesla has done right is making EVs with decent range that still, for the most part, still look like a normal car. Now if only Elon Musk would stop overstating the current capabilities of Autopilot, stop overpromising on things, and fix many of the build quality issues plaguing their cars, and maybe people will stop shitting on Tesla.

<comment><USER6> The gate is open now, I think the big guns (especially ze Germans) now recognise and are moving toward EVs.

Competition is good, although I don't think any particularly tribal Tesla fans will be pleased by the outcome.

<comment><USER5> I consider myself a huge Tesla fanboy, but the more I think about it, the more I think I'm really just an EV fanboy that thinks most of the non-Tesla offerings just haven't been up to par in one way or another.

The Model 3 set the standard. 200 mile range in the base model, 0-60 in under 6 seconds, and still generally looks like a normal car. I hope someone would correct me if I'm wrong, but I don't think there are any EVs made by anyone else that fit this description.

</comment></comment></comment></comment><comment><USER7> Also this : Elon 'Tusk'? Tesla CEO changes Twitter name, says there will be news on Thursday

[https://www.marketwatch.com/story/elon-tusk-tesla-ceo- change...](https://www.marketwatch.com/story/elon-tusk-tesla-ceo-changes- twitter-handle-says-there-will-be-news-on-thursday-2019-02-27)

</comment><comment><USER8> >Tesla shares fall nearly 2 percent</comment>