I’ve drafted an RFC to use a single canonical domain name (I’m proposing nix.dev, but there’s alternatives to consider) for all official resources, please take a look and give feedback via issues or PRs:
Note that I intend to use the approach from RFC 138 for this RFC in order to keep better track of discussions. So if anything is relevant to discuss for the RFC, please open an issue/PR to that repository instead of discussing here 
Can you enable the issue tracker on your repo? It’s disabled by default since it’s a fork.
Ah thanks for the notice, just did!
In fact, maybe it’s better to not to allow issues at all? Then proposals by design must be concrete, and all the heuristics for successful change management apply. I know this belongs to the RFC 138 discussion, but that apparently has stalled out.
RFC 138 is only closed because we couldn’t find shepherds at the time, it doesn’t mean we can’t discuss it there anymore!
I don’t think disallowing issues would work well. Sometimes people just want to leave a comment and that’s fine. Preventing them from doing so either means we don’t get the comment, or we get a bogus change request.
After what very nearly happened with .org (.org - Wikipedia), it’s important to consider which top-level domains are safest. I’m not an expert on this, but my tentative thought is that .net and .com are relatively safe. .dev belongs to Google, and they could decide to mega-monetize it.
Chiming in on the .dev discussion: some people seem to see it as sending the wrong signal, that the Nix platforms is just for developers. I don’t see that personally, I wouldn’t get too hung up on that, we use the nix.dev domain already and, while not perfect, it’s IMO fine.
I find the nix-platform alternative unwieldy to spell out, and the dash can be very easy to forget (and to squat the lack of it)
If there was something like nix.platform I would be on board, but it doesn’t exist, so I’m a 
for this name choice.
A thing that should IMO be explicitly mentioned is the Matrix space: I don’t think it should be in scope (I interpret the RFC as being about websites), but the RFC talks about “all official Nix projects”, so we should either make MXIDs explicitly out of scope, or figure out the interactions.
AFAIK Matrix IDs are permanent, so we couldn’t just rename the space to be :nix.dev. In that case, that would require us to keep the nixos.org domain around for as long as we keep Matrix around. Or have some transition (maybe using additional MXIDs?).
Just FYI: nix.org and nix.com appear to be available but held by MarkMonitor.
Does the NixOS foundation and/or Eelco himself hold trademarks on Nix/NixOS/Nixpkgs btw?
nixos.orgis confusing because it’s not just about NixOS.
I can kinda agree it ‘smells’ to have a website about “nix” with the domain “nixos”; but are there any examples in the wild of the domain name causing confusion?
Move the current contents of
nix.devto the subdomaindocs.nix.dev.
I’d keep in mind: the manuals are currently at https://nixos.org/manual/nixpkgs/stable/. If there is some docs.nix.dev, then perhaps eventually the other manuals could be accessed under that hostname too.
I’d appreciate issues/PRs for all of these concerns!
Just to be clear: what kind of contribution do you wish to have here on Discourse, as opposed to GH?
Anything not directly about the content, meta discussions. Things like suggestions about how to proceed, complaints about it being a repository, stuff like that (including this meta-meta discussion).
Any actual opinions/feedback about the content would be best in GitHub issues (or better yet, PRs), so that we can treat the issue tracker as the list of concerns to discuss and address.
how much are they selling them for? And second: would like to know who owns Nix/NixOS/Nixpkgs trademarks or whatnot
On the order of $10-90k according to information from a year back.
The Nix logo as a trademark is owned by the NixOS Foundation, but there is no policy in place at the moment.
I was about to write that one could help the foundation board by making concrete proposals for discussion, but adding more input may actually be counterproductive because the board is so time constrained already. Maybe the best way to really help is to distribute the load of weighing alternatives against each other and selecting one for a binding agreement to the community, and in fact run an RFC. That would not just be in line with the foundation’s stance not to impose decisions on the community but instead serve it by providing a legal entity that can do things a mere group of individuals can’t. It would also be a great demonstration of commons management, and help us refine our collective values and identity.
The board would still have to agree with the outcome to ensure the decision can actually be implemented, but that’s a small part of the total effort required for such a far-reaching issue.
Also someone would have to facilitate and drive the RFC, and for instance process inputs and curate the document. Anyone who tried it knows what I’m talking about. It’s quite a bit of work, but it doesn’t require the board’s involvement at all! Anyone can do it, and even abandoned partial results can be picked up by anyone.
@zimbatm @thufschmitt @domenkozar @ron @edolstra what do you think? Would that work for you?
One could argue that Nix is a component of NixOS, afterall the Github organization is called NixOS and there’s a NixOS foundation. If anything, I would try to move all the other community projects (r13y, nixpk.gs, nix.dev, nixos.wiki, etc.) under nixos.org.
AFAIK Matrix IDs are permanent, so we couldn’t just rename the space to be
:nix.dev.
Indeed, that’s a big issue with Matrix that has unfortunately received little attention. Until they manage to make messages mxids-independent in the future, the only way to migrate is to recreate all rooms, user accounts and use a script to auto-join the previous rooms. This works well enough but all the previous room history is lost.
I don’t think the board even needs to be involved in this decision. The NixOS Foundation’s role is to support the project, so as long as it’s a well-thought-out plan that doesn’t put the project at risk, it should be fine. Link to the Role of the board.
It would be good to consult with the Marketing team.
I know they are working on a new website. I think one of the challenges they had was to create a good landing page that works for everybody. It’s hard to serve different crowds at the same time. People interested in Nix the language vs nixpkgs and NixOS. Beginners, advanced users and commercial entities. Etc.
They might also have some considerations regarding Google search ranking and other aspects I am unfamiliar with.
I’m sure they have developed a more fine-grained vision of how this could look when mixed together. For such a deep-impact change, it would be nice to have a bit more of a vision of how it will look after the transition.
That’s exactly backwards for arbitrary historic reasons, and the very source of confusion that could be avoided by more precise naming, which this RFC is partially about.
That would be a great subject for the UX workshop on the last week of November 2023. We’ll have a world-class UX expert available for two days to work with anyone interested on just that. It would be so great if someone from the marketing team could participate. We were missing you sorely in the first two iterations! It would be also be great opportunity to provide a lot of input to this RFC. We’re incorporating learnings from the governance discussion at NixCon: No binding decisions at in-person events, just work done for everyone else to see.