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)

Re: Domain names and how they're used Lassi Kortela 26 Dec 2020 21:19 UTC

On 26.12.2020 20.02, Jonathan A Rees wrote:
> I have zero knowledge or awareness of 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 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 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 *, 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
> 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 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
<>? 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 on lists like the above.

> Creating new subdomains also violates the "cool URIs" rule
> ( 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 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 is probably more elegant than
dozens of different sites. I would say that it's cool.

> I like the 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.