Website requirements

[chrisdickinson]

Replacing #27 in order to pin this. I want give more context on the pending software design decisions we need to make in order to build out a website (this affects #102 and #103, which are much appreciated!)

the problem

Entropic needs a website, because:

1. In order to allow people to sign up for accounts, we use GitHub OAuth login for signup and token creation
2. In order to allow people to manage their account, we display a token management UI.
3. In order to aid discovery & vetting of packages, we want to display information about packages (dependencies, dependents, etc.)
4. In order to aid vetting of packages, we want to display information about package contents (styled, rendered package contents as html)

The current website doesn't have any styles, is likely inaccessible, and is hard for developers to extend. Importantly, it's also embedded into the registry service, which could present security & caching concerns down the line.

constraints, rakes in the yard, & open questions

splitting into services

At present, Entropic runs in a single process. Because certain tasks (like syncing external packages) are too time-consuming to run in the duration of a request/response cycle, we need to split this out into multiple services. Eventually, I believe we'll need 4 services:

1. The existing external registry API service we expose today, talking to...
2. A :sparkles:new:sparkles: internal api encapsulating our data stores that the website, worker, and registry service can leverage.
3. A :sparkles:new:sparkles: external website service talking to that same internal api
4. A :sparkles:new:sparkles: worker service for processing syncing requests, talking to the internal api

For the production entropic instance, @ceejbot took a clever approach with nginx proxy_pass's so that we can simulate privileged APIs for the website to use by mounting them on the registry at non-exposed routes (for example, /private/.) This lets us start working on the website without having completed the other two :sparkles:new:sparkles: apis. However, until we split out the website process from the registry process, web handlers will use HTTP clients to talk to internal handlers in the same process. We'll start this process for the registry as well.

This is quite a mouthful: this is all to say that when the website starts needing to get at registry data, please pull in @chrisdickinson and/or @ceejbot.

Single page app or Server Side Template Language?

We'll want to consider whether we use a server-side templating language like Nunjucks to render pages in a traditional fashion, or go a single page app route using something like React + Next.js. Right now I am leaning towards server side templating using Nunjucks (or similar):

• Our present Oauth & CLI signup needs lean on url routing. (They could, yanno, not. But.)
• Our form needs are pretty basic.
• SPA's introduce a certain level of maintenance complexity (bundling FE assets, etc.) Next solves this pretty nicely, which is one of the (many) things I like about it, but it's still a cost.

I could be wrong here, so please poke holes in this. What are we buying with a single page app?

CSS

Let us do the simplest thing that works, then iterate. I propose we use Tachyons for a base coat, then specialize with an added stylesheet. (When this gets unwieldy, that's when we should start looking into css-modules or css-in-js as an additional layer on top of tachyons.)

[venikx]

@superhawk610 I think one of the reasons why @varjmes mentioned Next.js is that you have DX from writing React on the server-side (so no templating). However, since you potentially can share some of the code with the client, you can decide to move parts of the logic which happened on the server the first time to the client and that part of the code would act like a regular client-side from then on.

Correct me if I'm wrong (never used Next.js).

[lacaulac]

Well, it's about how much we want to separate the display stuff from the "computed" stuff. I usually go with REST + CSR SPA so that I can really have a clean separation between the client and server. @venikx That sounds pretty logical to me.

[varjmes]

Next.js is written exactly how you'd write an app using create-react-app (for the most part). There is some structure that's different, and some different concepts. There's getInitialProps that fires before componentDidMount. There's a server, there's pages. I'm not sure why there's an assumption you can't share code, you do :) Would really recommend taking a read first.

https://nextjs.org/learn/basics/getting-started

Server-rendered by default
Automatic code splitting for faster page loads
Simple client-side routing (page based)
Webpack-based dev environment which supports Hot Module Replacement (HMR)
Able to implement with Express or any other Node.js HTTP server
Customizable with your own Babel and Webpack configurations

I am more than happy with Gatsby or something completely different, or just a HTML page. I just want everyone to have all the info 👼

[venikx]

I'm aligned with @zacanger. The main thing for me is making sure we choose something that doesn't make it hard for search engines (there are more search engines than google) to find and index the content. Both Next.js and Gatsby seem to do fine in that aspect.

[chrisdickinson]

An update: there's some infrastructural work ahead of this that has to get done (it's plodding along in https://github.com/entropic-dev/entropic/pull/135). Specifically, we need to separate the storage layer from the registry, and the website from the registry. This unblocks work on the website and allows us to get underway with #141. This'll have the affect of actually making the website displayed on www.entropic.dev controlled by the website service!

Once this work is ready, our next steps with the website will be a lot more concrete & we can start picking rendering approaches and frameworks.

[workingjubilee]

@maxnordlund Totally understandable and I don't mean to pick on you or anything. I just tapped that part of your remark because I wanted to express how... patchy and unexpectable my knowledge of JavaScript is, as a newcomer. I could start writing (very basic) function components within the hour of being shown them because JSX is awesome and easy to read, and honestly so are template literals. They're both ES6. I know naught else, and the abyss of pre-2016 JS, with its mysterious $ and % signs everywhere, is closed to me. 🙈

[superhawk610]

I mentioned a concern with Gatsby earlier that was never addressed that I think may make Next superior - while Gatsby and Next both tout "server-rendered by default", they have pretty different models (someone please correct me if I'm wrong); Next spins up a Node server and renders each request on demand, while Gatsby generates all possible routes ahead of time as HTML files, essentially sacrificing disk space for response time.

While I really like Gatsby's approach, this means prerendering static HTML for each version of each package every time any package's info changes (again, someone correct me if this isn't the case). I know there's some active work now on incremental builds, so this may change, but at present this is the case.

Additionally, any data used to render a route is also stored in the static build directory, essentially doubling the disk footprint.

Next's model is a bit slower per-response but I think it's the only real option at this (potential) scale.

[varjmes]

Not at all, @superhawk610. You would not need to generate a file for every package for every thing ever with Gatsby.

Because a Gatsby site hydrates into a React app after loading statically, Gatsby is not just for static sites. You can fetch data dynamically on the client, as needed, as you would with any other React app.

https://www.gatsbyjs.org/docs/client-data-fetching/

[superhawk610]

@varjmes right, but client data fetching and SSR are mutually exclusive, anything you do client-side won't be there for search engine crawlers and thus kinda defeats the purpose, right?

[workingjubilee]

There must be a way to fallback to SSR if the client can't run JS, isn't there?

[varjmes]

@varjmes right, but client data fetching and SSR are mutually exclusive, anything you do client-side won't be there for search engine crawlers and thus kinda defeats the purpose, right?

Sure! In this case I was correcting the assumption.

With SEO it isn't necessarily an all or nothing case with SSR/CSR, see https://medium.com/@benjburkholder/javascript-seo-server-side-rendering-vs-client-side-rendering-bc06b8ca2383 but getting decent SEO with CSR is not worth the effort when you can just go SSR.

[alexgarces]

I agree with @superhawk610 about Next.js over Gatsby. Some things can be solved via static pages (documentation for example), but package pages have to be rendered dynamically on demand. I also find Next.js much more simple. It's just like React, but with an extra method for SSR (getInitialProps).

[tunnckoCore]

Thanks to @superhawk610 that is here to share and stand my points and thoughts. :D

And I'm super amazed of the newcomer @workingjubilee thinking and comments. Congrats.

Yea, Nextjs might make more sense, because there will be tons of package pages. And even if they were gonna be only few hundreds it's impossible in Gatsby land - except re-running build, which gonna be insane.

[workingjubilee]

There must be a way to fallback to SSR if the client can't run JS, isn't there?

https://github.com/zeit/next.js/issues/575 Answer: yes. Next.js correctly provides for the dynamic in question. Of course it does. It feels so obvious reading the code! https://github.com/zeit/next.js/blob/master/packages/next/client/link.js

If the client is running JS, preventDefault kicks in and the request is completed to the API instead, else (or on initial load) it is a "miss" that goes to hit the rendering server. Then the rendering server peels data off the API instead, renders the page, and throws it at the client.

[varjmes]

Speaking to the Next team yesterday, they will be coming out with a feature that lets you decide which pages are SSR or CSR. You can also do CSR and no SSR already, apparently. But now I feel like I'm (not saying anyone else is) bikeshedding :)

the human tendency to devote a great deal of time to unimportant details while crucial matters go unattended

[jlengstorf]

To jump in with some Gatsby info:

Gatsby generates all possible routes ahead of time as HTML files, essentially sacrificing disk space for response time.

This is true. Gatsby will generate all pages at build time. The cost is disk space, which I'd argue is dirt cheap compared to scaling servers.

Gatsby has a proof-of-concept of incremental builds working, which would eliminate the need to rebuild every page — instead we'll just regenerate the pages that the updated data/files touch. This is coming, but not here yet. @KyleAMathews may be able to shed additional light on how and when this will work.

Gatsby can also handle client-only routes for data that doesn't need to be built ahead of time.

Another potential benefit of Gatsby could be security: all files are static and there's no server available by default. That means that an attacker can deface static assets, but there's no attack vector through the generated app to the server or underlying databases. (This, of course, doesn't apply to any client-side calls, but that's going to be true with any client-side code.)

To my mind the trade-off is that Next provides convenience through realtime SSR at the expense of additional devops complexity and overhead; Gatsby provides painless devops at the expense of rebuild lag.

[cdvillard]

I'd like to highlight a concern regarding the use of SPAs, and query those involved with this thread about it, specifically regarding React-based SPAs. I mean no disrespect at all to Gatsby or Next.js and their teams, but those platforms are based off of a framework controlled by a single corporate entity that gives permission to the community to use it.

As the spirit of Entropy is to specifically move away from a centralized company holding the majority of the cards, are we okay with the front-end going in the opposite direction? I don't mean to be pedantic or overly thematic here, but to my understanding, if Facebook drops React, with that move would go the majority of its technical development and support.

We do have other framework options that aren't centrally backed if we were to work on a SPA. I'd like to suggest Vue-based tools myself, as there are direct correlations to Gatsby and Next.js in Gridsome and Nuxt.js respectively. I grant that Gridsome may be a little too green for a project of this magnitude, but are we willing to consider Vue-based frameworks for the task?

[venikx]

If Facebook is going to closed source React, I'm 100% convinced there will be a hard fork and it will continue on as open-source. The community is just too big atm to stop progress instantly, when such event would occur.

Nevertheless, I think it would be unwise to not have an open mind about other frameworks, which solves similar problems. Personally I don't have any strong opinions about the frameworks, just about them solving the problems for entropic. I guess an "extra" wink to getting rid of the "corporation" could be an argument to use Vue as it's (not yet) "owned" by one. If we take the road for Vue I would suggest Nuxt, seems similar to Nextjs.

Edit: Nicer wording

[toddself]

I know this thread is long but have we thought about svelte yet?

I like that it “gets out of the way” and the latest version is real nice...

[cdvillard]

I like Svelte's focus on compilation (transpilation?), but I'm not sure that should be the first step forward. I say this from a place of ignorance, but does Svelte have enough of a user base that we can be sure people will comfortable contributing? At least with a popular framework out the gate, we'll know there's a higher likelihood of developers capable of jumping in.

[zacanger]

If the goal is to avoid big name company products, Preact is also an option, and it works with Next. The lead maintainer is a Google employee, but I believe the project is independent. I like Vue, but React or React-alikes would likely be more familiar to newcomers.

I've been keeping an eye on Svelte and it seems really neat, but I would think that for most contributors coming in, that would be a blocker, at least unless/until it's up there with with the big players (React, Ember, Vue, Angular).

[avickers]

I like Vue, but React or React-alikes would likely be more familiar to newcomers.

Let's go look at the number of Github stars on all of the projects under consideration. You're going to seriously argue that Vue isn't accessible enough? Arguing that Vue is somehow harder to pickup than React is an equally dubious assertion. There's probably a reason Vue ended up with more Github stars than React, in less time, and with millions of dollars less in marketing. That reason isn't that it provides a worse developer experience.

[varjmes]

"would be more likely familiar to newcomers" does not say anywhere in that sentence that Vue isn't accessible. Nor does it say Vue is harder.

It's evident you love Vue, and that's excellent! It's not as well known with beginners which is what I believe the above sentence was saying. Let's keep it chill pals :seedling:

[toddself]

@vickers if you could please tone down the aggressive attitude that would be fantastic. This is a place for friendly civilized chat, even if its about passionate topics like web frameworks. :)

[moogacs]

I am with Vue, what i really like in Vue and don't see in React is the code architecture

What about making a poll ?

[zacanger]

@avickers please don't misunderstand, I'm not saying I dislike Vue or think it's hard to learn. Vue is great, I really like Vue, and in some ways I think it's actually easier to pick up than React (especially the less fragmented ecosystem). It's just less widespread than React, at least for now (based on package download counts, Wappalyzer/BuiltWith stats, and GitHub's "Used By" count, not stars). That means that a new contributor to this project would probably be more likely to already be familiar with React than with Vue.

[avickers]

@zacanger I apologize for the snark.

Stack Overflow Developer survery 2019

I'll grant you that React is most loved by people that use it, and most desired by FEDs to add to their skillset, but Vue is second in both categories. After all of the different approaches that had been entertained here and given a fair shake, I guess I just felt Vue deserved better than a hand wave.

[venikx]

Both "Used By" and "Stars" are a bad metric to check the adoption rate and shouldn't really be used for the sake of arguments (imho). Both metrics have flaws. Stars displays "people like it" and used by only display adoption rate on Github (I believe?). Vue is big in Asia and I'm not sure how popular Github use is there.

Even if we decide to go with the Vue route, the fact it's supposed to be easier to pick up for beginners is an argument on it's own. React, Ember, Angular, whatever devs are able to pick it up fast and "new" frontend developers might have an easier time contributing (since it's supposed to be more approachable).

Can you do Github polls?

[cmmartti]

Can you do Github polls?

Any comment can be a poll. Just use the up/down vote emojis.

[zacanger]

There's also this https://app.gh-polls.com/ for more complex polls

[venikx]

Thanks, there ya go!

[workingjubilee]

I disagree foundationally with this poll.

1) FPtP is intolerable because it seeks to choose a winner who can acquire the most first-choice votes, not necessarily the most tolerable compromise, which makes it ideal for irritating people (just ask Americans, hey?). Which of course this poll defaults to. Informational video on more regarding this: https://www.youtube.com/watch?v=s7tWHJfhiyo 2) Relatedly, this poll has been loaded with many similar choices, necessarily distributing votes awkwardly amongst them. But also see point 8. 3) Many of the questions that have led to discussing Gatsby vs Next vs Preact vs yes even Vue are merely economic, as they involve tradeoffs of HD size vs CPU, and while many things have pointed at a future involving 100 more copies of entropic being hosted, the people footing the first bill right now for https://entropic.dev/ are @chrisdickinson and @ceejbot afaict. The reality of their hosting plans will logically have as much of a vote, if not more than anything, right now, and those are mere calculations that will not bend to the will of democracy. 3) Further, the reality of the economics of hosting plans is something I believe the initial 2 founders of this project have thought about more than me, so I would prefer to hear their reasoning about this before anything else, even if they were not ALSO footing the bill for entropic.dev 4) Again, it's going to be a site they are hosting, so if the poll says one way and they say another (for whatever reason), this has been a sham poll. If we pressure them to accept regardless, it has been a double sham, for it has been a poll that has betrayed our intent to help them. And we can now no longer know what they would've said in the absence of the poll because we pushed on anyways! 5) In addition, there have been arguments regarding "vision" and library compatibility with that, and I would like to hear what they have to say about how much anything indeed has to do with this, because all I had when I came here was the 30 minute talk and noticing some interesting patterns about npm usage. 6) Related to that, it's worth considering that Node went from an open software project to being sponsored by Joyent to being sponsored by the Node Foundation (which is apparently, in 2019, merging to make the OpenJS foundation? huh). 7) Part of why I said I'm in favor of more complete rendering libraries generally is because the differences between React and Vue are really an ocean of breadth smaller than their similarities. 8) Maybe we should chill and settle down in light of #160

[olingern]

I feel like this discussion is jumping ahead of ourselves. We need a stable API first and then figure out how sessions will work on the site. As of #135 there are no JWT's for authentication so we will need to authorize access on the server for now.

Injecting React, Vue etc. for better interaction in the future ( I think ) would be a more pragmatic approach and put less pressure on having an API that is unchanging. Search engine indexing is also of concern.

Perhaps we can chat about a server side templating language / CSS framework as a next step after #135 merges?

---

Addendum:

Just some considerations from the requirements that @chrisdickinson posted:

Markdown is pre-rendered on publish. It is stored at rest as HTML suitable for inlining. (Storage is cheaper than CPU cycles.)

Injecting this and rendering after page load doesn't sound ideal. Sending this along from the server after retrieved from the database sounds more performant and better for search engine crawlers.

We want i18n support. My experience with rich client apps has been that you end up having to generate multiple different asset bundles for each target locale (or else do some kind of code-splitting.)

The website should look to what comes of #115.

[zacanger]

@workingjubilee

2: I think the options in the poll were taken from the most common suggestions in this issue thread.

3, 4, 5: Definitely! I don't think anyone thinks this poll is in any way binding, I think we're just trying to get a feel for what people are leaning towards, since the issue comments have gone on for a long while and it's hard to sum up everything that's happened.

9: I don't think a core maintainer being offline for a bit means folks need to stop contributing ideas! No one's trying to force a decision through, I think everyone here is just trying to figure out what might be best for this project.

@olingern

I somewhat agree, but right now there's a small but slowly growing bit of server-side rendered content already in the form of template strings, and I think one driving thing behind the discussion here is wanting to head that off and settle on a real, planned, and maintainable solution before we end up with lots of disorganized rendering hanging around.

Also regarding pre-rendering Markdown on package publish, I think there should be more discussion around whether that's ideal. That's trading off disk or s3 space and publish-time cycles for render-time cycles, and some of the debate in this thread has been about whether that's even the right thing to do.

[olingern]

I somewhat agree, but right now there's a small but slowly growing bit of server-side rendered content already in the form of template strings

@zacanger Totally agree. The template strings aren't ideal and I wanted to suggest using a template engine. A few suggestions:

• https://github.com/mozilla/nunjucks
  • Mozilla project, still being maintained
• https://github.com/olado/doT
  • No deps, but last commit 2017
• https://github.com/pugjs/pug
  • Defacto templating language, good docs, battle tested

---

RE S3 storage:

That's a hard problem. It would be neat if we could push to S3 and serve as a static site and then iframe the package HTML via the packages s3 static site URL. This would push the loading off to the user's browser and S3 at the expense of an additional network request. I'll admit maybe not practical.

Perhaps it's worth opening a thread on discourse to chat pros / cons of storing HTML vs doing it at runtime?

[zacanger]

@olingern I think starting a thread over there would be good!

[avickers]

Amazon S3 + Amazon CloudFront

[olingern]

Done. Discourse discussion here.

[venikx]

@workingjubilee 1: True, but that’s not the intention of the vote, it’s by no way binding. It’s just to get a feel of what people here are thinking, because we all have so many opinions it’s hard to see a summary. 2: I just put in the options I read on this thread. You can vote on multiple options either way. 3: See 1 4: See 1 5: Again, see 1 6: I don’t see what this has to do with the poll? 7: See 6 8: See 6 9: Disagree, I don’t think we should stop discussions, because one of the core members is on holiday.

If it wasn’t clear enough: My intention of the poll was not to set something in stone, but to get an idea of what people think of doing right with the information we got about the requirements. It’s by no means binding, especially since there is not clear “winner”.

@olingern If it comes down templating language, I would fine with a mature one, which is actively maintained. No preference there, since I don’t have experience with templating language, but that’s fine.

I disagree with the point the discussion is getting ahead of itself, since that was the part of why the issue was opened: templating language VS something like Nextjs.

[venikx]

Seeing the discussions about how dirt cheap storage is, I’m thinking maybe gatsby would be a super viable approach. I kinda brushed of gatsby, because I was thinking it would cost a lot due to amount routes we would need for all the packages.

But if storage scales better than cpu cycles, Gatsby becomes actually a super viable option + if anyone wants to run their own it’s straightfoward since it’s “just html”. Accessible, straightforward and a friendly community ready to help as seen in: https://github.com/entropic-dev/entropic/issues/107#issuecomment-500029072

I’m unsure how two things work with gatsby though:

• Authorizarion
• Publish to registry would require redeploy of the FE if I’m not mistaken

[avickers]

Gatsby doesn't yet support incremental builds. Sounds like they think they are getting close.

Obviously rebuilding 800k pages with every publish would be the most expensive approach in terms of CPU. Maybe there is some clever way to break it up, like every namespace getting its own Gatbsy instance, that would mitigate this problem?

[superhawk610]

every namespace getting its own Gatbsy instance

That actually would work, the only difficulty there would be dynamically creating instances on namespace creation. Tbh I think incremental builds would essentially do this.

I still really want Gatsby to work since it will only require a rebuild on package creation/update, while Next will rerender each page every time it’s requested, but until they support incremental I don’t think it’s really viable.

I wonder if there’s some happy medium we could hit using Next - have an Express server running to serve the app, but whenever a route is first requested, render it and cache the HTML to disk and then just serve that on subsequent requests? Then any time a package is updated, we just delete the cached copy as part of the update process and it will be regenerated on the next request. For efficiency, we could even perform the render/cache on package deploy/update, effectively having our own Gatsby-esque solution. Thoughts?

To address @venikx other question, Gatsby apps are just basic React SPAs once they’re rehydrated so you can use any existing auth solution however you normally would (request a token from the backend and then store it locally and use it to authenticate outgoing requests).

[jlengstorf]

every namespace getting its own Gatsby instance

There's support for prefixing, so a URL structure of /:namespace/* would allow for an instance-per-namespace setup. Gatsby themes would allow for all common code to be rolled up into a single shared package to avoid the need to duplicate code between instances.

Incremental builds in Gatsby aren't too far off, either, so in the near- to mid-term this issue will resolve itself upstream.

[michaelpumo]

For your tech stack, I would certainly argue in favour for Vue JS with its SSR partner Nuxt JS.

It’s inspired by React’s use in Next, yet much simpler to get running with, easy HTML templating and CSS setup. I believe it to be a much more accessible setup that would welcome new contributors warmly.

In the spirit of this project, Vue (unlike React or Angular) is NOT back by a large company (Facebook and Google respectively). It was started by one person but is now a truly open source, community-led framework.

Lastly, if you wish to go with a CSS class based utility library I would recommend Tailwind over Tachyons.

That’s just my thoughts.

[jhonalino]

phew, that's a long thread of framework debate.

just start with nunjuck, and vanilla js, css.

and add react later.

[evomedia247]

Keep it simple ... don't reinvent the wheel, and don't try and reach perfection on your first build. Who really cares if its in Angular, React, Vue, or even Aurelia or Knockout or Jquery. I'd just say concentrate on being able to quickly refine based on your user behaviours is key at the start. Lets be honest an SPA feels slicker, but when your starting, just doing the simplest route to get something up is far better than creating some ultra complex Angular monster say.

Personally I'd build a simple prototype, throw up a super simple knockout.js based view model as it involves no build steps, I'd add in something like wasabi on a docker image to run AB tests and set up a load of goals, like completes a sign up form, links to the git hub repo. And start testing the users.

I'd add redirect functionality to attach tracking codes off URLs to segment the users and see where they are coming from to start measuring what is driving traffic, ie ads, talks, articles, social media etc.

If your doing a simple content only sire, then there are some decent headless cms systems like Crafter cms, or craft cms that take a few minutes to get up and running and then you get no major config or environment headaches.

Then build out from there, refine, refactor and renew

[Vickers]

Please remove me from this group.

On Thu, Jul 4, 2019, 10:15 AM evomedia247 notifications@github.com wrote:

Keep it simple ... don't reinvent the wheel, and don't try and reach perfection on your first build. Who really cares if its in Angular, React, Vue, or even Aurelia or Knockout or Jquery. I'd just say concentrate on being able to react and refine based on your user behaviours. Lets be honest an SPA feels slicker, but when your starting, just doing the simplest route to get something up is far better than creating some ultra complex SPA.

Personally I'd build a simple prototype, I often just throw up a super simple knockout.js based view model as it involves no build steps, I'd add in something like wasabi on a docker image to run AB tests and set up a load of goals, like completes a sign up form, links to the git hub repo. And start testing the users.

Add redirects to add tracking codes to segment the users and see where they are coming from to start measuring what is driving traffic, ie ads, talks, articles, social media etc.

If your doing a simple content only sire, then there are some decent headless cms systems like Crafter cms, or craft cms that take a few minutes to get up and running and then you get no major config or environment headaches.

Then build out from there, refine, refactor and renew

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/entropic-dev/entropic/issues/107?email_source=notifications&email_token=AAHEX4EPSZ5FAMQ4NQPKPUDP5YAXZA5CNFSM4HSBNOZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZHQ53Y#issuecomment-508497647, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHEX4DNV4IHKOWIDSTT423P5YAXZANCNFSM4HSBNOZQ .

[toddself]

@Vickers we cannot remove you from this list -- you'll need to either use the mute thread link at the bottom of the email, or view the thread on github and click the unsubscribe button.

Sorry :(