3 ms·

Nyxt already exists, and fits your description perfectly

sylware 2y ago
Indulge me and let me be lazy and answer this question: Is Nyxt _NOT_ just a front-end to one of the Big Tech web engines? (blink|geeko|webkit) I would be super pleased to be wrong...
- sourcepluck 2y ago
  Oh sorry, just realised I replied to my own comment instead of yours :D see my response above!
sourcepluck 2y ago
Nyxt is basically a front-end to the Big Tech web engines, yes, but one that (I think sincerely, from my not-overly-technical standpoint) attempts to re-empower the user. I didn't understand your original point about needing "a modern web browser" with "a simple language" (I'm not sure it was clear, by itself...), but I read your other comments, and I understand your point better now, I think. I agree that "open source" itself is absolutely not enough, and that another prerequisite to fighting for practical computing freedom is to have "human"-sized tools. Fully on board with that (I wonder if you've seen the malleable systems forum, actually...). I think Nyxt would love to provide that, eventually, and are trying to fight that fight, on a stacked battleground, in an imperfect world. For example, gopher and gemini are supported. And they're trying to support different renderers. They're trying to make the browser fully configurable and programmable as far as they can, in spite of the shortcomings of the web. Tell me if this is completely beside your point, but in case it helps you in seeing what they're about, have a look at: https://nyxt-browser.com/article/command-line-programs.org https://nyxt-browser.com/article/command-line-programs.org Or, much more technical, too technical for me, and it's a bit dated so the exact design might have changed, but maybe you'll get something from the overview nonetheless: https://nyxt-browser.com/article/technical-design.org https://nyxt-browser.com/article/technical-design.org Maybe that's not enough, and you think the solution has to be more radical, but I don't know what it would be, other than a new set of networking protocols comes along and somehow supercedes the ones we have now. Which could happen, I don't know, I'm only still only learning about the ones we currently have :D Also, have you seen surfraw? Or do you have examples of the kind of thing you'd like to see being attempted in the wild? I'd be curious to see them. p.s. I responded to a point you made 8 days ago about email in a different thread [https://news.ycombinator.com/item?id=42287607 https://news.ycombinator.com/item?id=42287607] and thought I'd say to you here in case you'd be interested in elaborating over there!
- sylware 2y ago
  This was a ironic comment: the grotesque and absurd complexity and size of a Big Tech engine (google blink/geeko | apple webkit) with their SDK (c++ compilers, gcc/clang) kill any "real-life" attempt at interop. You would need many, MANY good devs, for a significant amount of time to maybe acheive 'real-life' compatibility in, pheeew, some significant amount of time... if ever... And even when you get something "working", don't forget they control also the online services requiring their pieces of software... namely those guys will have to play cat and mouse about interop: permanent little changes on Big Tech services (more or less justified) and Big Tech web engines, breaking any other alternatives... I think you get the picture. And that is exactly the same issue with the c++ language syntax and its compilers (that would be the same issue with other complex computer languages like rust/java/etc). Seriously, I would go for a modular implementation directly in 64bits RISC-V assembly with a very small macro-preprocessor (because, moving the complexity from the language syntax to the macro-preprocessor would be riduculous). That's why, from this perspective, those small attempts are kind of pointless and even somewhat dishonnest since, in the end/'real-life', they are just font-ends of Big Tech... The email people did see the DNS "barrier" coming: it has always supported literal IPv4 addresses (and a similar IPv6 literal has been in specs for ages). Using the "excuse" of spam/phishing of script kiddies, they blocked IPv4 literal support and ignored the subsequent IPv6 literal support. If I recall well, IPv4 literal support was a thing on google mail a few years ago (even IPv6 if I recall properly), it means it was explicitely blocked. Then to get SMTP interop with them: you MUST rent/pay for a domain name, and in the last few years, very slowly but surely (I did live it, horrible), the DNS registars did stop working without a Big Tech web engine (they were working fine with lynx or links or netsurf, namely noscript/basic (x)html, which is more than enough, actually even overkill). Basically, they have big services, and they made sure that, slowly and in the end, you must use their software for their services, and they could not careless of the small alternatives even if the internet protocols did account for this. This is compuserve/AOL all over again. The remaining/surviving "small" did just cave in and is part of the problem now. The only sane way out of this "dominance" is to restore interop with simple , but good enough to do the job, and really stable in time protocols. And restoring 'interop' won't happen asking nicely: only hardcore _technical_ regulation can do it now. All is about technical interfaces: the very hard part is they must be simple and stable in time, _while doing a good enough job_. Ofc, things may significantly change, significant new usages can arise... then new simple and stable in time technical interfaces will have to be designed (but one or a small number of average devs should get it implemented in a reasonable amount of time), or new simple and stable in time "layers" added an an existing technical interface (the core of the dynamic web is noscript with basic (x)html forms, and I think it is already way too complicated). A set of layered and modular technical interfaces, but all simple and stable in time. Ofc, if there are billions of interfaces required to support a basic use case, there is something wrong somewhere... I did reach a point where I would not be even surprised if they did shadow-pay hackers to bring down any simple and stable alternatives. It far from easy to deal with all of this.

Indulge me and let me be lazy and answer this question: Is Nyxt _NOT_ just a front-end to one of the Big Tech web engines? (blink|geeko|webkit) I would be super pleased to be wrong...

sourcepluck 2y ago
Oh sorry, just realised I replied to my own comment instead of yours :D see my response above!

sourcepluck 2y ago

Nyxt is basically a front-end to the Big Tech web engines, yes, but one that (I think sincerely, from my not-overly-technical standpoint) attempts to re-empower the user. I didn't understand your original point about needing "a modern web browser" with "a simple language" (I'm not sure it was clear, by itself...), but I read your other comments, and I understand your point better now, I think. I agree that "open source" itself is absolutely not enough, and that another prerequisite to fighting for practical computing freedom is to have "human"-sized tools. Fully on board with that (I wonder if you've seen the malleable systems forum, actually...). I think Nyxt would love to provide that, eventually, and are trying to fight that fight, on a stacked battleground, in an imperfect world. For example, gopher and gemini are supported. And they're trying to support different renderers. They're trying to make the browser fully configurable and programmable as far as they can, in spite of the shortcomings of the web. Tell me if this is completely beside your point, but in case it helps you in seeing what they're about, have a look at: https://nyxt-browser.com/article/command-line-programs.org https://nyxt-browser.com/article/command-line-programs.org Or, much more technical, too technical for me, and it's a bit dated so the exact design might have changed, but maybe you'll get something from the overview nonetheless: https://nyxt-browser.com/article/technical-design.org https://nyxt-browser.com/article/technical-design.org Maybe that's not enough, and you think the solution has to be more radical, but I don't know what it would be, other than a new set of networking protocols comes along and somehow supercedes the ones we have now. Which could happen, I don't know, I'm only still only learning about the ones we currently have :D Also, have you seen surfraw? Or do you have examples of the kind of thing you'd like to see being attempted in the wild? I'd be curious to see them. p.s. I responded to a point you made 8 days ago about email in a different thread [https://news.ycombinator.com/item?id=42287607 https://news.ycombinator.com/item?id=42287607] and thought I'd say to you here in case you'd be interested in elaborating over there!

sylware 2y ago
This was a ironic comment: the grotesque and absurd complexity and size of a Big Tech engine (google blink/geeko | apple webkit) with their SDK (c++ compilers, gcc/clang) kill any "real-life" attempt at interop. You would need many, MANY good devs, for a significant amount of time to maybe acheive 'real-life' compatibility in, pheeew, some significant amount of time... if ever... And even when you get something "working", don't forget they control also the online services requiring their pieces of software... namely those guys will have to play cat and mouse about interop: permanent little changes on Big Tech services (more or less justified) and Big Tech web engines, breaking any other alternatives... I think you get the picture. And that is exactly the same issue with the c++ language syntax and its compilers (that would be the same issue with other complex computer languages like rust/java/etc). Seriously, I would go for a modular implementation directly in 64bits RISC-V assembly with a very small macro-preprocessor (because, moving the complexity from the language syntax to the macro-preprocessor would be riduculous). That's why, from this perspective, those small attempts are kind of pointless and even somewhat dishonnest since, in the end/'real-life', they are just font-ends of Big Tech... The email people did see the DNS "barrier" coming: it has always supported literal IPv4 addresses (and a similar IPv6 literal has been in specs for ages). Using the "excuse" of spam/phishing of script kiddies, they blocked IPv4 literal support and ignored the subsequent IPv6 literal support. If I recall well, IPv4 literal support was a thing on google mail a few years ago (even IPv6 if I recall properly), it means it was explicitely blocked. Then to get SMTP interop with them: you MUST rent/pay for a domain name, and in the last few years, very slowly but surely (I did live it, horrible), the DNS registars did stop working without a Big Tech web engine (they were working fine with lynx or links or netsurf, namely noscript/basic (x)html, which is more than enough, actually even overkill). Basically, they have big services, and they made sure that, slowly and in the end, you must use their software for their services, and they could not careless of the small alternatives even if the internet protocols did account for this. This is compuserve/AOL all over again. The remaining/surviving "small" did just cave in and is part of the problem now. The only sane way out of this "dominance" is to restore interop with simple , but good enough to do the job, and really stable in time protocols. And restoring 'interop' won't happen asking nicely: only hardcore _technical_ regulation can do it now. All is about technical interfaces: the very hard part is they must be simple and stable in time, _while doing a good enough job_. Ofc, things may significantly change, significant new usages can arise... then new simple and stable in time technical interfaces will have to be designed (but one or a small number of average devs should get it implemented in a reasonable amount of time), or new simple and stable in time "layers" added an an existing technical interface (the core of the dynamic web is noscript with basic (x)html forms, and I think it is already way too complicated). A set of layered and modular technical interfaces, but all simple and stable in time. Ofc, if there are billions of interfaces required to support a basic use case, there is something wrong somewhere... I did reach a point where I would not be even surprised if they did shadow-pay hackers to bring down any simple and stable alternatives. It far from easy to deal with all of this.