This is a draft document that covers what our policy is for creating sub-domains of hyperledger.org (such as wiki.hyperledger.org or grid.hyperledger.org).

For reference, a list of sub-domains as of March 2022 is available at: Hyperledger DNS

Types of Sub-Domains

We currently have different types of sub-domains and there may be a different criteria for each type. The types of sub-domains are:

  • Project sub-domains (such as grid.hyperledger.org that points to stand-alone sites for some projects)
  • Language sub-domains (such as es.hyperledger.org that points to localized content on www.hyperledger.org)
  • Services sub-domains (such as wiki.hyperledger.org that points to a tool that is used by the community)
  • One-off sub-domains (such as challenge.hyperledger.org that points to a stand-alone site for some activity or group other than a project)

Criteria for creating a Sub-Domain

Each category may need to have a different criteria for determining if we create a new sub-domain.  Some thoughts for each category:

  • Project sub-domains: There are a few open questions about this that the TSC may have thoughts about:
    • When is it appropriate for a project to have a sub-domain?  For example, is it tied in to additional support for reaching graduated status or not?. 
    • How is the project site hosted and does the TSC and/or Hyperledger staff have access to edit and update the site and get analytics?
    • How is the site branded and designed?  Do we want there to be some consistency across project sites so it is easy for people to navigate multiple project sites?
  • Language sub-domains: Staff will set this up when a new language is added to the site
  • Services sub-domains: Staff will set this up when a new tool is added to the community
  • One-off sub-domains: The TSC may have some thoughts on criteria for this – perhaps the criteria should be about the sub-domain needing to relate to an officially sanctioned community activity?

Process for requesting a Sub-Domain

If someone is interested in a sub-domain, they can reach out to the Community Architects alias.

  • No labels

3 Comments

  1. Peter Somogyvari

    > When is it appropriate for a project to have a sub-domain?  For example, is it tied in to additional support for reaching graduated status or not?.

    Could go on the list of carrots for graduated projects, that might be a good idea.

    The important variable for this question to me is the cost. If the foundation will provide a budget for the web hosting, then even more so it should be for graduated projects.

    We could also say that sub-domains are available for all incubated and graduated projects, but when you graduate a budget gets allocated for it. All this is assuming that we even want a budget. My personal take on the budget is that we should just try and use free tier tooling because there seems to be so much of it anyway (more details in my other answers below)

    > How is the project site hosted and does the TSC and/or

    If a member organization wants to pay for hosting, they could, otherwise we could provide a recommended list of hosting platforms with free tiers. One example that comes to mind is Netlify which has great GitHub integration where you can store the source code of a web application in a GitHub repository and their CI/CD pipeline pushes the main branch's contents to the web automatically.

    Instead of mandating where something should be hosted I'd say the TSC should provide recommendations for those who need ideas.

    > Hyperledger staff have access to edit and update the site and get analytics?

    I would say yes, because it is a sub-domain of the hyperledger.org domain.

    The nasty edge cases I can think about right now is what if a website gets hacked, defaced or even worse, is made to serve malicious payloads to its visitors.
    In this case the community on the internet would assume that this is the foundation's "fault" because the domain is owned by the foundation and so in my opinion if the foundation is responsible for the domains then it should also have some (joint) control over it.

    To be clear: I'm not asserting that any project would have any less competence in keeping their website safe than the TSC/HL Staff, I'm just saying that for these cases it's probably best if multiple groups of people have access/ability to double check configuration/perform updates/etc.

    All the above is reinforcing my belief that deployment architectures where a CD pipeline is involved would be great because then authorization to push content to the websites would be possible to be managed directly through the HL GH org permissions.

    > How is the site branded and designed?  Do we want there to be some consistency across project sites so it is easy for people to navigate multiple project sites?

    Some consistency would be nice, but instead of mandating it we could provide a lot of helpful material for this and ask people to make a best effort to use them/comply with the theme.
    Relevant anecdote: No one ever told me that I must use the HL presentation slide templates, but I love using them because they are making my life easier as a maintainer who is trying to evangelize Cactus or HL in general.


    > One-off sub-domains: The TSC may have some thoughts on criteria for this – perhaps the criteria should be about the sub-domain needing to relate to an officially sanctioned community activity?

    Makes sense to me. If someone wants to create a sub-domain on the domain then it should be for something is relevant to the org/community. Should almost go without saying IMO, but never hurt to have it written down explicitly so that we can quell spam without having to discuss it first.

    1. David Boswell

      Peter Somogyvari – Thanks for your response to the different points in the draft policy.  I think your suggestions make sense.  Looking forward to discussing more at a TSC call.

      1. Arun S M

        Few comments

        For 1 & 2: If the website is hosted through GitHub pages, it shouldn't be additional cost to Hyperledger Foundation as far as I know. This will also let the staff to take appropriate measures or any of the other community members to maintain.

        For one-off-sub-domains: My view is that Hyperledger staff can decide if having a sub-domain makes sense or not. TSC can recommend must include contents for community as a reference. Generally, all sub-domains are to be reachable from the main website. Otherwise a subdomain is not worth it. The alternative is to have a sub-domain completely dedicated to such activities (say community.hyperledger.org), from where further sub-domains can be created (ex: challenge.community.hyperledger.org). This sub-domain goes with a disclaimer. But still list all the allotted sub-domains under the main website.