Reddit 1.0 source code
github.com
github.com
And what's more, Reddit themselves did not even use that excuse in their official statement for it, even though to me their excuse felt even less logical.
Basically, they don't want to leak the crazy features that they're developing and have such piss-poor source code management that they cannot provide tarballs of clean states of their source code.
I mean, how do they deploy new versions, if they cannot cleanly separate feature development from stable code?
https://www.reddit.com/r/changelog/comments/6xfyfg/an_update...
Anti-abuse is useful to keep secret because it includes tools that make spammers think they're successful. I think it's a little more nuanced than the "open source code is more secure argument", which I totally agree with - but the anti-abuse includes active mitigation measures that constantly evolve; and in this case, obscurity to how this all works is actually valuable.
A reddit-specific ad or metrics implementation isn't useful to anyone else, and it was a tough sell that the codebase should be made more complex only to accommodate configuration for a small handful of users. I know, because I made the argument that we should when I created the open-source reddit-mobile repo, which was originally broken up into plugins like the reddit python codebase. Eventually it just wasn't feasible to maintain as a 2-5 engineer team rebuilding a 10-year-old website in a couple of months. That's a story for another time.
Personally - I find it sad, and I think it got rid of one more thing that made Reddit special. Unfortunately, the only metric you can attach to this is "how much longer does it take us to ship shit", and thus, it died.
That's the same as saying that humanity is capable of building a large system without bugs, in an economically viable way.
If you take a quantitative, cost-based approach to modeling security through adversarial capability, obscurity becomes a perfectly valid security measure if it's not used in isolation. We don't use it for cryptography because the tradeoffs aren't worth it. It's better to design cryptography with provable security based on mathematically rigorous computational hardness assumptions than it is to make secret algorithms.
In the context of application security, if the decision to obscure some or all of your system incurs a non-trivial cost to an adversary, it makes sense. We can't rigorously and mathematically prove the security of applications in the same way we can prove e.g. an algorithm is sub-exponential instead of polynomial time.
You often see "security through obscurity" mentioned in the same way that people cite "appeal to authority" or "ad hominem" fallacies in internet debates. The reality is more complex than that. Fundamentally, anything that increases the effort required by an adversary to successfully compromise your system is worth considering. You just shouldn't depend on it in its entirety. Closed-source software is a good example of robust security through obscurity, as basically any security engineer will tell you (I'd rather look at source code line by line to find vulnerabilities than try to find them through trial and error in a penetration test).
Btw, from the wikipedia article: "lazy cipher clerks often chose starting positions such as "AAA", "BBB", or "CCC"" Weak passwords were an issue already back then.
It's also quite interesting to see that the Polish cryptanalists were able to reproduce the enigma machine used by the german army without even having seen one. They were able to deduce the number of rotors, the wiring, etc.
What in the end doomed the Enigma was the fact it was more a kitchen recipe than cryptography based on solid principles. It was a smart recipe for the time, but it had flaws (like the fact a letter could not be the same letter once encrypted). In some regards, most of our symetric encryption algorithms today feel a bit that way (with a lot more external scrutiny from experts however).
Even in WWII, I don't think that security through obscurity was considered as an absolute barrier. It's more in line with a "defense in depth" pattern. It gives a little more work to your adversary as he now has to figure out how your encryption works before breaking it, but it's not expected to last for long.
The trivial counterexample is that all modern crypto techniques rely on keeping a key, or part of a key, secret. That's security through obscurity, and you've just stated bluntly that obscurity never works under any circumstances, right?
What you want to do instead is talk about tradeoffs. Talk about how much information you need to keep secret in exchange for a given window of effectiveness, and state a preference for systems which provide longer windows of effectiveness while requiring less information (such as only a key, or part of a key, instead of a key and an algorithm) to be kept secret.
Also, take care with your argument about "pre-modern crypto techniques". Some of them remained effective for centuries after being invented, which is a far cry from your "cannot be argued that they worked", and not necessarily a favorable comparison with many modern techniques, which are lucky if they make it a couple decades before being broken.
(also, of course, all cryptographic systems eventually get broken, which is why every so often we switch to new algorithms, longer keys, etc., and you seem to be arguing that any system which eventually gets broken is a system which never worked, and that's also wrong)
Using a public algorithm with secret key is BY DEFINITION _not_ security through obscurity. On the contrary.
Unfortunately, I started my reply to the wrong comment and didn't notice until after I'd posted it and it was too late to edit/delete.
tl;dr too many people have a knee-jerk "security through obscurity!" reflex action to things they don't like, and I have a reflex action of yelling at them about it, which sometimes misfires when I don't take care to reply at the right point in the thread.
Just something to keep in mind.
For example, if your way to encrypt works like this:
1) Shift all letters along by 5.
2) Cut out every second word and put them behind the message in order.
3) Whenever there's an f, s or y in a word, double up that word and shift the second word's letters by 7.
Then if your enemy figures out how your method works, you have to come up with a completely different method.
The opposite to security by obscurity would instead once come up with a method that entirely depends on a key. You can then publicize that method (or not), and if your enemy finds out your key, you just choose a new key and you're fine again.
On the other hand, with closed source, people are presumably being paid to study the code, potentially fewer but a still fixed number of eyes on the code, as it were. But then, since it's closed source, no one really knows what's going on outside the company.
Moral arguments aside, neither system is perfect.
You really didn't say much about open source and it's ability find bugs; you just cited a particularly nasty set of bugs on an open source project as a way to condemn all of open source work to being as bug-ridden as other methods.
It was more snark than it was providing a clean example as a counter-point. Someone could easily point out the millions of bugs in closed source projects as a counter to your point of equal caliber; but I think that it's clear to most of us that NO methods that we yet understand will result in bug-free code.
[0]:https://simple.wikipedia.org/wiki/Kerckhoffs%27s_principle
It's either their secret super sauce or it's poison.
And I can tell you for free that whatever Reddit has built technologically, does not contain any secret super sauce whatsoever.
Until there is a way to easy 're-key' such an algorithm if someone found a way to abuse it, holding it secret is the best solution for them.
I currently can't think of a better solution to avoid gaming of ranking algorithms than holding it secret and changing/adapting it often. Maybe some machine learning algorithm?
When in JavaScript, I'd always lean on TypeScript. Is there something similar for Python?
https://medium.com/@ageitgey/learn-how-to-use-static-type-ch...
(defun login-panel ()
(pbox "login/register"
(:form :id "logform" :class "nomargin"
(:table :style "border-collapse: collapse"
(:tr (:td :colspan "2" "username:"))
(:tr (:td :colspan "2" (:input :id "loguser" :class "txt" :name "user" :type "text" :size 15)))
(:tr (:td :colspan "2" "password:"))
(:tr (:td :colspan "2" (:input :id "logpass" :class "txt" :name "pass" :type "password" :size 15)))
(:tr (:td :colspan "2" (:input :id "logmem" :type "checkbox" :name "mem" "remember me")))
(:tr (:td :colspan "2" (:span :id "logerror" :class "error" "")))
(:tr (:td (:input :id "logbtn" :class "btn" :type "submit" :value "Login" :onclick "login(); return false"))
(:td (:input :class "btn" :type "submit" :value "Register" :onclick "register(); return false")))
(:tr (:td :nowrap t :colspan "2" :align "center" :class "little" (:a :href "/password" "what's my password?")))))))What you are looking at was designed by a designer.
Maybe you think another designer you know could make something that looks better if only they could use their own tools, instead of tools that this designer liked to use.
I remember an age when I would receive photoshop "designs" that I would have to re-code in HTML. Then they got dreamweaver and thought they didn't need me to code their stuff up anymore, just to debug their stuff and tell them why it didn't work in X/Y/Z browser combination.
When the lisp programmer is writing their login panel, they start out writing "code" like this,
(defun login-panel ()
(pbox "login/register"
(:form :id "logform" :class "nomargin"
(:table :style "border-collapse: collapse"
(:tr (:td :colspan "2" "username:"))
(:tr (:td :colspan "2" (:input :id "loguser" :class "txt" :name "user" :type "text" :size 15)))
(:tr (:td :colspan "2" "password:"))
(:tr (:td :colspan "2" (:input :id "logpass" :class "txt" :name "pass" :type "password" :size 15)))
(:tr (:td :colspan "2" (:input :id "logmem" :type "checkbox" :name "mem" "remember me")))
(:tr (:td :colspan "2" (:span :id "logerror" :class "error" "")))
(:tr (:td (:input :id "logbtn" :class "btn" :type "submit" :value "Login" :onclick "login(); return false"))
(:td (:input :class "btn" :type "submit" :value "Register" :onclick "register(); return false")))
(:tr (:td :nowrap t :colspan "2" :align "center" :class "little" (:a :href "/password" "what's my password?")))))))
<form id="logform" class="nomargin">
<table style="border-collapse: collapse">
<tr><td colspan="2">username:</td></tr>
<tr><td colspan="2"><input id="loguser" class="txt" name="user" type="text" size="15"></td></tr>
<tr><td colspan="2">password:</td></tr>
<tr><td colspan="2"><input id="logpass" class="txt" name="pass" type="password" size="15"></td></tr>
<tr><td colspan="2"><input id="logmem" type="checkbox" name="mem">remember me</td></tr>
<tr><td colspan="2"><span id="logerror" class="error"></span></td></tr>
<tr><td><input id="logbtn" class="btn" type="submit" value="Login" onclick="login(); return false"></td>
<td><input class="btn" type="submit" value="Register" onclick="register(); return false"></td></tr>
<tr><td nowrap="t" colspan="2" align="center" class="little"><a href="/password">what's my password</a></td></tr>
</table>
</form>
Maybe this one and bigger we could move into a file and either read it every request or add some extra code to save the contents to a global variable. But we haven't gained very much for all that complexity -- this hypothetical "when" we get a designer who knows HTML and not Lisp, and can contribute in a way that meaningfully moves the project forward without making more work for other programmers is far away at this point, and the reddit developers are just going to rewrite the whole thing in Python anyway.
I mean, templates are a thing people use.
I think you implied that in your last point but I'd be curious to find a designer who knew lisp better than HTML.
That doesn't benefit our designer who knows lisp well enough, and it doesn't benefit our programmer who knows lisp very well (or they would have done it).
> I'd be curious to find a designer who knew lisp better than HTML.
Well, if your team is a handful of lisp developers, then all of them.
Perhaps buried is the assumption that hiring/resources are free, or that there is some kind of gatekeeping for the term and title "designer". If it helps to make the point clearer: I program and I design, and I know lisp better than I know HTML.
"Confusing and hard to grok"† is in the eye of the beholder. Syntax highlighting and indentation go a long way (as well as exposure), though even in black and white, the parens fade for me much more than angle brackets do. Personally, I'd wrap some of the longer lines, but that's a style thing.
[0]: https://docs.racket-lang.org/html-template/index.html.
[1]: https://github.com/weavejester/hiccup
[2]: https://mustache.github.io/mustache.5.html
† Sorry. Couldn't let the typo stand. Heinlein made me do it.
RE designer thing, I guess it depends on how you work. Frankly, Reddit to this day doesn't look like anything that has ever met a designer (and that's a good thing in its case). Still, if you want, you can just stick to the designer that does mockups in Photoshop, and skip the other designer that converts those into HTML.
Even without the transpilation step for JSX support, I find hyperscript [0] and friends [1] a notable improvement over other templating tools. Instead of having to jump to a separate file which magically inherits a bunch of implicit globals, you just call a function. If the system supports a component abstraction you can import them and compose views using the same programming constructs you use everywhere else.
An error in the template can be caught by your linter or compiler, since it's just regular code. I'd say it's actually safer, since you typically won't have to worry about escaping values manually. And along the way you can validate the input in order to confirm you only ever generate valid HTML.
Check out elm-css [2] as well, which lets you define your stylesheets with elm. This lets you take advantage of the their type system to make sure all class names are referenced correctly. A typo or accidental deletion would would cause it to fail to compile, allowing you to catch problems early.
[0] https://github.com/hyperhype/hyperscript
That said, glue-strings-together templates are still a problem and should not be used. HTML document is semantically a tree, and if you don't treat it like that, bugs and security vulnerabilities follow.
(Respecting semantics applies to other languages as well. For instance, those who recognized SQL as a language, instead of some blob you concatenated out of strings, didn't have to worry about SQL injection.)
Because if you're working on a team, not everyone on your team may be a programmer, particularly if they're just working on layout design, and the problem that templates solve in that regard don't require complete access to raw code. Separating one from the other makes it easy to focus on one versus the other. Just look at how messy a complex Wordpress template can get and how difficult it can be, just reading it, to get a grasp of what the HTML would look like, versus a Twig template which has a lot less noise.
>Especially that I saw it becoming popular in PHP, which itself is a better templating language than the templating languages people were using.
I've been down the road with PHP where everyone working on javascript and CSS also had to know just enough PHP not to break the site, because everything had raw PHP mixed into it, and then somewhere in the vast tree of includes including includes someone forgot to manually escape a variable that came from the database, or else they did, but now someone else escaped it twice, or they created some weird encoding problem because they were in a javascript context.
PHP is at best an adequate templating language, and a good base to build a sane framework on. But a framework is necessary beyond a certain level of complexity, because most projects benefit from features that raw PHP doesn't provide, such as context-aware and automatic variable escaping, template inheritance, template caching, etc. You will either wind up using an existing templating framework, or you will wind up implementing an ad-hoc, informally-specified, bug-ridden, slow implementation of an existing framework.
>That said, glue-strings-together templates are still a problem and should not be used. HTML document is semantically a tree, and if you don't treat it like that, bugs and security vulnerabilities follow.
There's no way to get that in PHP without a template framework. PHP, unfortunately, doesn't even know that HTML exists[0], despite having the sole purpose of being an HTML preprocessor.
[0]I just remembered there are XML functions like DomDocument that can be used to process HTML (with... effort) but I don't know whether or not you could get something like XHR out of it, and by extension, avoid the problem of HTML as concatenated strings.
I think we're rapidly getting to the point in our civilisation that that's a bit like having an illiterate on the team. All programming is, is thinking logically & systematically about abstractions: everyone should be capable of thinking like a programmer — anyone who can't has a cognitive disability (like those poor folks who can't learn to read).
Fortunately, people who can't think logically & systematically about abstractions are pretty rare; people who won't think logically & systematically are sadly far, far too common.
But not every aspect of web development is programming, any more than every aspect of book publishing is typesetting, or every aspect of film is camerawork. It's a lot more complex than it was when you could be a "web developer" with just Notepad++ (unfortunately.)
And we're not talking about "thinking like a programmer" in this case, but literal programming. Someone whose job it is to translate a Photoshop image or PDF into HTML and CSS can be capable of thinking in abstractions but still not need to write python or PHP or what have you.
.. I meant XHP, not XHR, can't edit it now. Oops.
Do you mean that (:td :colspan "2" "username:") is verbose and error-prone compared to <td colspan="2">username:</td>, or what are you comparing it to? That code is probably denser than I would have written it, but I don't see any issue related to the fact the HTML is being generated from Lisp.
This example doesn't take advantage of it, but writing HTML in Lisp is easier and less error-prone than regular HTML, because you can abstract patterns and factor things.
To our parent's points, it's more verbose if you're used to passing data into a separate template file. That can help abstract the markup from the data processing. To their point regarding designers, many are more comfortable working with HTML files than application code. That can be a benefit for many teams. Clearly some lispers agree, as they've implemented alternatives like Mustache templates.
> To our parent's points, it's more verbose if you're used to passing data into a separate template file. That can help abstract the markup from the data processing.
One does not exclude another. The "template" can be another lisp function (in another file).
> Clearly some lispers agree, as they've implemented alternatives like Mustache templates.
Probably popular demand. Personally, I don't think they should be used, like ever. Those template languages were a doubly bad idea.
First, they work on HTML serialization to string instead of HTML semantics as a tree, making it easy to introduce both bugs and security vulnerabilities. The concepts of "escaping", "sanitization" or "injection" are only relevant when you're abusing a serialization format instead of working with the language at the appropriate level.
Second, they all seem to have started with the assumption that "views don't need code". Each of them, over time, slowly discovered that no, views actually do need to have code, and slowly gained variables, conditionals, loops, function calls... and turned into shitty Turing-complete languages they tried so hard not to become. The problem here was always the premise. Views absolutely do need code, and so they should be written in a proper programming language.
For example, imagine if you want to test some HTML code in a browser. Browser doesn't understand Lisp so you have to write it in HTML. And then you have to convert it to Lisp to use as a template. What a waste of time.
There are all king of template languages around. There are editors that can highlight the syntax, there are plugins to write HTML faster. I don't imagine how you justify writing your own template engine. Probably that is just a NIH symdrome.
> First, they work on HTML serialization to string instead of HTML semantics as a tree, making it easy to introduce both bugs and security vulnerabilities.
This can be easily solved by validating HTML code.
> The concepts of "escaping",
Tenmplate engines do necessary escaping automatically. For example, in Twig you just write
<div>{{ user.getName() }}</div>
> Views absolutely do need code, and so they should be written in a proper programming language.
In my experience, template engines like Twig have enough features. If you need soem complicated logic, you can write a helper function.
Which is what turned them into Turing-complete languages that try to pretend they're not.
> For example, imagine if you want to test some HTML code in a browser. Browser doesn't understand Lisp so you have to write it in HTML. And then you have to convert it to Lisp to use as a template. What a waste of time.
Not much time is wasted, especially that s-exps are faster to write than HTML (especially with editor support). Browsers don't understand templates either, so in both cases you have to do some conversions. I'll give a point to HTML-ish template languages here, but I don't believe the time spent on manually converting large chunks of template code into browser-edible HTML and back is anywhere near the critical path on the project.
> This can be easily solved by validating HTML code.
That's validating vs. making it literally impossible to emit invalid HTML.
> I guess in Lisp you cannot even write user.getName() because it doesn't have objects.
Haha. Right. No, Lisp actually has objects. You'd write it as (get-name user), since the syntax for function calls in Lisp is consistent.
(pbox "login/register"
(form (text "username:" :name "user")
(pass "password:" :name "pass")
(check "remember me" :name "mem")
(group
(button "Login" :onclick "login(); return false")
(button "Register" :onclick "register(); return false"))
(link "what's my password?" :href "/password")))And you can do the same thing with template engines like Twig with macros. Futhermore, Web frameworks like Symfony already have macros that are necessary to display a form. You don't even have to write them and that is a strong point of Symfony compared to weird self-made Lisp template engine.
This thing has no concept of localization, is that a constraint? Accessibility? Are there dozens of other engineers working at this level of detail you need to worry about? Is this the output of a higher level tool used by either coders or designers? Is there a coherent component architecture behind this or is it just more of a utility function someone made? Do components need to be namespaced? Live in their own files/packages? Is the thing you're building a site with several unique pages or a SPA? Where are the JavaScript implementation points for things like the on-click's register() function? Or are you going to forbid JS in your markup (because it confuses designers, or because of CSP policy) and force programmers to bind things elsewhere? How does your routing system work, is it fine to hardcode those paths like that?
That looks a lot less verbose, error-prone, confusing & hard-to-grok than actual HTML, don't you think? Or do you actually prefer the HTML below?
<form id="logform" class="nomargin">
<table style="border-collapse: collapse">
<tr><td colspan="2">username:</td></tr>
<tr><td colspan="2"><input id="loguser" class="txt" name="user" type="text" size="15"/></td></tr>
<tr><td colspan="2">password:</td></tr>
<tr><td colspan="2"><input id="logpass" class="txt" name="pass" type="password" size="15"/></td></tr>
<tr><td colspan="2"><input id="logmem" type="checkbox" name="mem"/>remember me</td></tr>
<tr><td colspan="2"><span id="logerror" class="error"/></td></tr>
<tr><td><input id="logbtn" class="btn" type="submit" value="Login" onclick="login(); return false"/></td>
<td><input class="btn" type="submit" value="Register" onclick="register(); return false"/></td>
</tr>
<tr><td nowrap="true" colspan="2" align="center" class="little"><a href="/password">what's my password?</a></td></tr>
</table>
</form>
As someone who doesn't, the HTML example is 100% easier to read in my opinion coming from a Rails developer. You don't have to go against the grain to get the output you desire, you can just write it as it is intended to be rendered.
And of course in the context of writing lisp code it means that you have a uniform syntax instead of having some parts of the file as HTML and others in an other language (which is often a pain with code editors in my experience).
It still baffles me that SGML and its descendants are so popular. They're quirky, terribly noisy for markup, incredibly large and slow for serialization and of course every variation introduces and removes arbitrary limitations.
</closingtag> vs )
<form><table></form></table> oops. Can't happen with an s-expressionAnd this can result in sites that are very fast to add things to, as opposed to have dozens and dozens of files everywhere.
But everyone wants "single page apps". Because
client -> server ---[html]--> client --> server --[javascript]--> client --> server --[4*ajax requests necessary to fill in the initial page]--> client --> server --[4*images necessary to fill in said javascript]--> client
client -> server --[html+embedded everything]--> clientIt's not error prone maybe even less so since it can be checked by the compiler.
My preference is to use templating because it matches the final output closer and is, like you said, easier to show to other people / designers. However, even templating is sometimes turned into an enterprise confusing mess where it becomes very complex and hard to know where values come from.
[1] https://github.com/archimag/cl-closure-template [2] https://developers.google.com/closure/templates/
As far as it being typical... given the zeal that lispers seem to have for s-expressions, yes probably.
[0]https://github.com/wting/hackernews/blob/master/news.arc#L38...
A programmer will translate it to something manageable eventually anyway. A trivial automatic process can convert HTML to a DSL. Although making code sensibly refactored and readable is usually a manual job for the programmer.
(email
:type string
:accessor user-emai)
[1] https://github.com/reddit-archive/reddit1.0/blob/bb4fbdb5871...
%assertion-failure doesn't look like an accessor.
http://clhs.lisp.se/Body/f_car_c.htm
car described as "accessor", not named %car. No public function in CL is named this way. In fact, the character % doesn't make an appearance at all:
http://www.lispworks.com/documentation/lw50/CLHS/Front/X_Per...
I've never named a function or macro %something in 18 years of Lisp.
Edit: ah, I think I understand. I don't mean to imply that all accessors should be named in this way. That would be gross.
So if we have a user-email function that is just an object slot accessor, We could have %user-email that actually does a database query. I can't remember for sure, but I wouldn't be surprised if I'd seen a double %%-prefix used, too.
You don't always want to put those functions in separate packages (traditionally in Lisp, packages are relatively heavyweight--e.g. an entire web server framework might have only one or two packages).
Another similar example might be the convention of defining a macro with the name my-macro, and a function that actually implements much of the macro, or is an equivalent of the macro that takes a thnk, that is named my-macro*.
(24 years of lisp here--I wouldn't be surprised if the conventions of mainstream lisp during the earliest six years were somewhat different than the following decades.)
Edited to add: Now that I think about it, this convention may have been heavily used in the Macintosh Common Lisp community.
That's why I linked to some CCL code (descendant of MCL).
I use foo-impl and such for the implementation of foo.
If I have a my-macro, which is implemented by an expander function, then I call that function expand-my-macro.
It's quite fantastic to be schooled by old-time lispers (only 6 years of lisp here).
In application code, this is just a smell.
To prevent clashes, there are packages.
What will you do if three or more modules want the same function name? Tack on %%, %%%, ...
> What will you do if three or more modules want the same function name? Tack on %%, %%%, ...
Certainly not!
I think your points are all very fair: it would be a smell, and is evidence of a need for improvements at a more structural level. It just smells a little less than a seemingly purposeful misspelling to my nose.
Beyond that, this is actually fascinating to look at. It's small enough that you can actually understand it, but it's more complete than a simple 'toy' application. I'm also fascinated to see how SQL constructs are expressed in LISP. I don't know LISP at all, but it's pretty obvious how the queries in the language map directly to SQL.
https://news.ycombinator.com/item?id=3815491
Of course HN is written in Lisp. pg is a big fan:
I'm guessing reddit.asd lists some:
:tbnl (a toolkit for building dynamic websites)
:cl-ppcre (a regex library)
:trivial-http (a HTTP client)
:cl-who (a library for using S-expressions as HTML markup templates)
:clsql (a SQL database interface and ORM)
:clsql-postgresql (a PostgreSQL connector)
:cl-smtp (a SMTP client for sending email)
:ironclad (a cryptography library)
The stack I used for a website just the other day:
hunchentoot
cl-who
postmodern (prefer it over clsql-postgresql)
cl-smtp
ironclad
drakma (fuller featured than trivial-http)
Some Ediware in the dependencies (CL-PPCRE, CL-WHO and Hunchentoot from back when it was called TBNL). I guess they used CL-SQL rather than Postmodern because the latter didn't exist back then.
Should be reasonably easy to get it running on a modern CL.
I don't believe the mainstream archive sites would be a definitive source. Perhaps there is another?
> "When we set out to rewrite our code to solve these problems, we wanted to make sure we weren't just fixing small, isolated issues but creating a new, more modern frontend stack..."