Domain names and how they're used
Jonathan A Rees
(26 Dec 2020 18:02 UTC)
|
Re: Domain names and how they're used
elf
(26 Dec 2020 18:50 UTC)
|
Re: Domain names and how they're used Lassi Kortela (26 Dec 2020 21:19 UTC)
|
Re: Domain names and how they're used
Arthur A. Gleckler
(27 Dec 2020 02:31 UTC)
|
Re: Domain names and how they're used
Lassi Kortela
(27 Dec 2020 12:36 UTC)
|
On 26.12.2020 20.02, Jonathan A Rees wrote: > > I have zero knowledge or awareness of scheme.org or its history, and > no stake in it. However I did have a few thoughts in response to a > proposal I saw recently about future governance of the domain name. > While as a bystander I am reluctant to voice them on this list, I was > urged to do so by a list member, and am honoring that request. I hope > you will understand if I decide to drop out of the discussion after this. > If you read this, thanks for the extended comments! > > Long term domain name (and, of course http resolution) governance is a > difficult problem and I'm glad people are starting to understand this. > Thank you. > > I think having lots of delegated subdomains is a terrible idea. It > saves a little bit of money over having lots of separate domains, but > vastly increases the attack surface for the main domain > It's not primarily about the money. It's about organizing everything under one banner. If you have a dozen different top-level domains, they are not obviously connected to each other. A hub like Schemers.org that redirects to external sites is useful, but does not reinforce the idea that the sites belong together. That brings us to the main issue: Should we work toward uniting sites, making them easier to find and more cohesive when taken as a whole? "No" is a valid answer, but it's the past and present answer and gives the results we've had thus far. In other words, we already have the thing you seek. The Scheme.org revival project was started by people who believe we should make a serious attempt on a different approach. We have been mindful of security from the start. That's why the plan is that the main admins are only responsible for direct administration of DNS, not subdomains' servers. In practice, the same people can and do wear more than one hat, but that's explicitly not a requirement. > by increasing the number of html (and other) pages that are served > under *scheme.org, each of which is potentially an attack on the > reputation of the main domain name. E.g. if one subdomain gets turned > into a phishing site or hate site or DMCA violator, that taints trust > in the whole domain, and may even cause the whole domain to be > blacklisted or blocked or worse. I wouldn't advise the scheme.org > owner(s) to trust the administrator of every subdomain, given the > goals of loose federation and low administrative overhead. > Is that really true? It sounds like questionable design for one subdomain to always flag an entire domain. For example, how can githubusercontent.com and many other such domains avoid being flagged? There must be a mechanism in place for a main domain's owner to disavow responsibility for subdomain content. Perhaps <https://publicsuffix.org/list/public_suffix_list.dat>? Many household names appear on that list. There ought to be no immediate problem: I've visited more or less all of the Scheme implementations' sites, as well as general resources like the wiki, and haven't come across any material anywhere that would reflect badly on the site's ratings. For the long term, we should investigate putting Scheme.org on lists like the above. > Creating new subdomains also violates the "cool URIs" rule > (https://www.w3.org/Provider/Style/URI). We already have URLs for all > these sites. It makes no sense to create new ones. If the problem is > paying the DNS fees, figure out a different solution for that. E.g. > you could find or create a payment or payment insurance structure that > these sites could opt into. > Redirects solve all of that. Old URIs can redirect to new ones, or new ones into old ones. As far as web technology is concerned, it doesn't matter which way the redirect goes. > > I also am skeptical that the current domain owners will want to move > their projects to subdomains; all my experience with this kind of > thing says that establishing the required level of trust is basically > impossible, and no one will want to do it. > So you're saying we're on exactly the right track. Perfect! Scheme is very much like a plant that needs watering. Needs a refresh. For that to happen, we have to complete several impossible projects. I believe this is one of them. > It would only happen when a site is being deliberately abandoned - and > even then, almost always, abandonment is unplanned and absolute, and > there is no opportunity for handoff. Everyone will always say that > collaboration is a good thing; but no one will say they are willing to > trust someone else to perform a critical function for their project, > especially in the absence of consideration (contract / payment). > That's why we eventually need formal bylaws. > > You can't have a site that's both "open" and reputation-protecting - > so there will necessarily be a governing board of some kind (call it > what you will) charged with reviewing (perhaps by delegation) the web > content served at the site (including subdomains), and with selecting > new board members as people leave. Deliberations (meetings and other > discussion) can be public but not the decision making. Ultimately the > composition and action of the board is going to be capricious to some > extent - at the very least the board and governance structure will be > gated by the current legal owner of the domain name, according to any > criteria they choose. You just have to accept that 100% neutral is > impossible, as is 100% invulnerable. 100% neutral is not attainable and not necessary. We should aim for minimalism in governance. That's the most likely route to approximate neutrality over the long term. > > I think I'm saying that the core idea of preserving a 'hub' domain for > scheme is fine, but scrap the subdomain idea, and keep the site very > lean (goes to reputation and ease of administration), with links out > to other domains, not to subdomains. Having a sufficient number of > board members that know the domain account password (understanding > that password holders get bored, get sick or busy, pass away, etc. so > there has to be redundancy) and make sure the fees are paid is really > the critical thing. > This is good advice, but I continue to believe in subdomains. Are there other arguments against them besides the reputation systems? There are so-many domains where millions of users can publish anything anytime that there has to be a system in place to account for that. > Not that I have good visibility into current developments but I'm not > sure the word "community" applies to Scheme; > That's one of the foremost impossible problems facing Scheme. And Scheme.org is one of the main impossible projects that would help with it. It's only natural that the detail work will still be done in somewhat isolated communities, but currently we have _no_ centralized community. That's weird. You could argue that C and C++ don't have centralized communities either. But that's a drawback! A centralized website for C++ with an index of C++ libraries and documentation would be incredible, if well executed. People just need to have more imagination. A lot of the things in this world are the way they are because people made something that works and then got complacent in their success. Not because there's some kind of natural law by which those things have to be that way. > any hub will always represent only a slice of the population that > cares about the language, just as the scheme-reports process did not > include everyone who cares about it. That's fine, but I would > discourage the message that any particular DNS domain is associated > with "ownership" or "governance" of the language itself. > I know what you mean to say, and it's technically correct, but to a layman that sounds like a practical joke: you can't ask about the owner because anyone who claims to be the owner is by definition not the owner. That bears an uncanny resemblance to a community where no-one takes responsibility for the whole. Lisp had an edge (pun intended) over other languages by virtue of the fact that many of our heroes were intellectual pranksters and rebels. But there comes a point when the rebel attitude no longer works. Resistance is a negative, defensive goal - not a positive, expansive goal. Successful resistance eventually comes to a point where you no longer have a sensible opponent to resist. Lisp probably passed that point somewhere in the 1990s. It's now a rebel without a cause. Lispers keep resisting out of habit and cultural DNA, and our imaginary oppressors are strawmen from the mainstream dissing us (when the reality is that the mainstream simply ignores us). Lisp is not a teenager anymore. Vacillating between rebelliousness and self-effacement as our default attitude no longer serves us. The boring technical detail is that the closest thing to Scheme's owner is probably the Scheme Steering Committee. That doesn't matter. What matters is that we stop passing the buck on organizing our community like a group of teenagers trying to skirt responsibility over whose turn it is to clean up. That is also funny, and that also does not build a community. We're adults and we should clean up the place and get it done. > On 26.12.2020 20.23, elf wrote: > If I may add something... Comments are always welcome and appreciated. > there is a certain irony in making an extremely complex and overloaded > domain for a language whose simplicity and elegance is the strongest > attractor/selling point. I don't see the irony. The core of calculus is simple and elegant, yet there's a great variety of extremely complex books and applications everywhere. A constitution can be simple and elegant, but there are countless interpretations and endless debate. Whenever humanity succeeds at inventing something, the next step is to expand outward from the invention as much as possible. A simple and elegant invention gives us the power to expand faster and better than a clumsy and complicated one, but expansion is still the goal. The point of diving into the core of a discipline to find the core principles is to eventually make our way back out and fill the world with the fruit of that knowledge. If elegance is the goal, one Scheme.org is probably more elegant than dozens of different sites. I would say that it's cool. > I like the schemers.org domain. It's been around for forever. It's > arranged nicely with links to relevant information (standards, srfis, > implementations, projects, etc). It's minimal. It works equally well > in a pure text-based browser as it does in the newest beta release > bugpack from *insert favourite timewaster here*. It's extremely low > maintenance. It's worked in essentially the same way since its inception. > > These are many of the same points that I (we?) love about scheme itself. This is possibly a generational issue; the best answer I can give is to check out the websites of other programming languages to find out what we're missing out on. Perhaps the most substantial single thing we should have behind the site is a comprehensive index of Scheme that drives the user-visible parts of the site. Once you have a central index, a central domain is a natural extension of the idea. Some people are temperamentally opposed to centralization of all kinds, and Scheme is a magnet for people with that inclination. But we already have de facto decentralization, and also de jure decentralization by virtue of the slow-moving RnRS supplying only the core language and everything else being up to implementations. If we add centralized infrastructure on top of the current decentralized ones, what do we lose? > Instead of focusing on a replacement for something that really doesn't > need replacing, why not spend the mental energy on, for example, a > discussion regarding if and how sockets could/should be incorporated > into the traditional ports paradigm, or if and how a > scheme-semi-agnostic FFI would look, or other such matters that could > actually affect the future of the language as a whole. Many of the > things most requested are the same ones that are most > implementation-specific - which leads to greater and greater > divergence, and increasingly less chance of coming to future > agreement/standardisation. Those are fine ideas, and several people would like to work on them at some point, but they are orthogonal to websites. I'm skeptical of the idea that people can be removed from one project and moved onto another project at will; people tend to work best on things they personally care most urgently about.