> It would be awesome if lips could be hosted on your sever, but nice thing
> about GitHub pages is that I've got Jekyll build on each commit for free. In
> order to connect git repo on GitHub with your server I would probably need
> something more then just static hosting. I can check if I can use GitHub
> actions to just upload static files to different server and build the files
> using GitHub actions. I would need SSH access probably, but simple ftp would
> also probably be fine. But I'm not 100% sure if simple hosting would work with
> GitHub actions, since I recently watched video about GitHub actions and the
> guy used VPS with root access to set this up.

We only use SSH (with keys, not passwords) for access to the server. We
don't use plain FTP, but sftp, scp and rsync work. I believe this is the
recommended security setup nowadays.

If you can get GitHub Actions to upload files using rsync, that would
probably be easiest. It looks like there are several options:
<https://duckduckgo.com/?q=github+actions+rsync>. We could make you a
user account on the server and add your SSH key to authorized_keys. The
bot should probably have its own user account and SSH key.

> One note: I have tracking on lips.js.org right now, it use my private instance
> of Piwik (Matomo) but I don't use the data in any way, I just visit from time
> to time dashboard and see how many visitors I've got, that + Google Webmaster
> tools help be improve the SEO of the site.
>
> With my Piwk I can enable every possible privacy option, so it make sure that
> it don't store any sensitive data.
>
> Maybe I will switch to something lighter since Piwik is very heavy and
> sometimes overload my cheap shared hosting with too many php processes.

That sounds more heavyweight and difficult to admin than we can expect
our volunteers to handle. PHP and its various applications have had lots
of security holes in the past so we'd probably want to isolate any PHP
application pretty well, perhaps using Docker containers.

For the shared scheme.org servers, it would probably be best to have one
server that serves only static files. Then put each dynamic application
on its own server (or one server with each application in its own Docker
container). Convenience is always at odds with security and ease of
maintenance. Since Scheme.org is trying to unite many groups with
different preferences for a long time, it pays to be quite conservative
about the core technology.

> I'm not exactly sure how this works with redirect that you have, that is more
> on DNS side. But with normal 301 redirect it's recommended to use it because
> when you change the domain and old one is indexed in Google, new one will get
> the same ranking, you just move the ranking from old to new domain. Even when
> there are links pointing to old domain.

That sounds good. We're using DNS CNAME and HTTP 301 for redirects.

> Also giving new domain that is not
> indexed redirect to old domain that is indexed is kind of pointless in SEO
> perspective. The new domain that is redirect, will probably never got indexed
> by Google.

Even if the new domain is later changed not to be a redirect?

> My domain js.org is pretty new, I only have few links and I can change
> everything, also I'm in process of creating new website, so it would be great
> if new website have new domain. and domain will have name of the language
> which is keyword that people search using so it would be great.

Sounds good!

> One problem with js.org is that I will need to manually change all the links
> that I've added, to have any links to new site because js.org don't offerer
> redirect so I will need to setup a site that would have a link to new website.

I see. It's good to know how js.org is doing things for making decisions
about scheme.org. We're trying to be more flexible by allowing
subdomains to be redirects.