New proposal for a set of links on the front page Lassi Kortela (28 Dec 2020 14:31 UTC)
Re: New proposal for a set of links on the front page Arthur A. Gleckler (28 Dec 2020 16:25 UTC)
Re: New proposal for a set of links on the front page Lassi Kortela (28 Dec 2020 17:01 UTC)
Re: New proposal for a set of links on the front page Arthur A. Gleckler (28 Dec 2020 18:06 UTC)
Re: New proposal for a set of links on the front page Jakub T. Jankiewicz (28 Dec 2020 19:19 UTC)
Re: New proposal for a set of links on the front page Marc Feeley (28 Dec 2020 22:05 UTC)
Re: New proposal for a set of links on the front page Lassi Kortela (28 Dec 2020 22:49 UTC)
Re: New proposal for a set of links on the front page Jakub T. Jankiewicz (29 Dec 2020 08:42 UTC)
Details on privacy and tracking Lassi Kortela (29 Dec 2020 11:41 UTC)
Re: Details on privacy and tracking Lassi Kortela (29 Dec 2020 11:43 UTC)
Re: Details on privacy and tracking Jakub T. Jankiewicz (29 Dec 2020 12:49 UTC)
Re: Details on privacy and tracking Lassi Kortela (29 Dec 2020 13:06 UTC)
Re: Details on privacy and tracking Jakub T. Jankiewicz (29 Dec 2020 16:15 UTC)
Re: Details on privacy and tracking Lassi Kortela (29 Dec 2020 16:40 UTC)
Gambit and other JavaScript Schemes Lassi Kortela (29 Dec 2020 12:11 UTC)
Re: Gambit and other JavaScript Schemes Lassi Kortela (29 Dec 2020 12:17 UTC)
Re: Gambit and other JavaScript Schemes Jakub T. Jankiewicz (29 Dec 2020 12:55 UTC)
Re: Gambit and other JavaScript Schemes Lassi Kortela (29 Dec 2020 13:14 UTC)
Re: New proposal for a set of links on the front page Marc Feeley (29 Dec 2020 14:38 UTC)
Aspects of JavaScript Schemes Lassi Kortela (29 Dec 2020 14:55 UTC)
Re: Aspects of JavaScript Schemes Marc Feeley (29 Dec 2020 15:11 UTC)
Re: Aspects of JavaScript Schemes Lassi Kortela (29 Dec 2020 15:27 UTC)
Re: Aspects of JavaScript Schemes Jakub T. Jankiewicz (29 Dec 2020 16:54 UTC)
Re: Aspects of JavaScript Schemes Marc Feeley (29 Dec 2020 21:35 UTC)
Re: Aspects of JavaScript Schemes Jakub T. Jankiewicz (29 Dec 2020 22:33 UTC)
Re: Aspects of JavaScript Schemes Jakub T. Jankiewicz (29 Dec 2020 16:36 UTC)
Re: New proposal for a set of links on the front page Lassi Kortela (29 Dec 2020 15:04 UTC)
Re: New proposal for a set of links on the front page Arthur A. Gleckler (29 Dec 2020 16:19 UTC)
Re: New proposal for a set of links on the front page Lassi Kortela (29 Dec 2020 16:30 UTC)
Re: New proposal for a set of links on the front page Arthur A. Gleckler (29 Dec 2020 16:38 UTC)
Re: New proposal for a set of links on the front page Lassi Kortela (29 Dec 2020 16:46 UTC)
lips.scheme.org implementation subdomain Lassi Kortela (28 Dec 2020 22:28 UTC)
Re: lips.scheme.org implementation subdomain Jakub T. Jankiewicz (29 Dec 2020 08:04 UTC)
Hosting and SEO for Scheme implementations Lassi Kortela (29 Dec 2020 12:35 UTC)
Re: Hosting and SEO for Scheme implementations Lassi Kortela (29 Dec 2020 12:43 UTC)
Re: Hosting and SEO for Scheme implementations Jakub T. Jankiewicz (29 Dec 2020 13:20 UTC)
Re: Hosting and SEO for Scheme implementations Lassi Kortela (29 Dec 2020 13:45 UTC)
Re: Hosting and SEO for Scheme implementations Jakub T. Jankiewicz (29 Dec 2020 17:13 UTC)
Re: Hosting and SEO for Scheme implementations Lassi Kortela (29 Dec 2020 17:43 UTC)
Re: Hosting and SEO for Scheme implementations Jakub T. Jankiewicz (29 Dec 2020 18:34 UTC)
Re: Hosting and SEO for Scheme implementations Lassi Kortela (29 Dec 2020 18:46 UTC)
Re: Hosting and SEO for Scheme implementations Arthur A. Gleckler (29 Dec 2020 16:28 UTC)
Re: Hosting and SEO for Scheme implementations Lassi Kortela (29 Dec 2020 16:35 UTC)
Re: Hosting and SEO for Scheme implementations Jakub T. Jankiewicz (29 Dec 2020 17:21 UTC)
Re: Hosting and SEO for Scheme implementations Lassi Kortela (29 Dec 2020 18:15 UTC)
Re: New proposal for a set of links on the front page Jakub T. Jankiewicz (29 Dec 2020 20:05 UTC)
Scheme tutorials Lassi Kortela (29 Dec 2020 20:16 UTC)
Re: Scheme tutorials Jakub T. Jankiewicz (29 Dec 2020 21:44 UTC)

Re: Hosting and SEO for Scheme implementations Lassi Kortela 29 Dec 2020 13:45 UTC

> 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.