My Cool Home Page

I think I'll be clear about this: I am not anti-Mozilla.

(Though putting Pocket in their addressbar rather than an RSS/Atom subscribe button does go against my design principles for encouraging a more decentralized web)

I think they are a positive influence, but they have too much influence to loose to be as radical as they pretend to be.

At the same time we do need a truly radical browser engine to help get us out of the sad software development we're in. I hope to be that!

@alcinnz I think things started to go downhill around the time Brendan Eich was told to go.

It's one of the earliest cases of this modern era of cancel culture; especially when it comes to attributing a specific moralistic opinion as either virtuous or dangerous

@djsumdog @alcinnz Eich wasn't the beginning of the decline, it was already well underway at the time of his forced departure.

@djsumdog Personally I think the problems broader than Eich, Mozilla, or even the web. As I said I think Mozilla are a positive influence.

But it's appropriate to mention Eich, as I see the beginning of the web's downfall as being JavaScript. Still can't blame Eich because *someone* was going to add *some* programming language to the web, even if it wasn't him.

@djsumdog @alcinnz ah yes, cancel culture is when a CEO steps down and becomes CEO somewhere else

@mhmd @alcinnz So if he was a grocery store cashier, that would make it okay?

@mhmd so what's the yearly income amount someone has to be below for cancel culture to be bad when applied to them?

@djsumdog like 10 or 15 maybe

@alcinnz @djsumdog yeah Eich, Pocket, CORS, telemetry, SSL, Addon signing, secure_delete, experiments.enabled, Mozilla is getting fucked up and thanks to the wealth disparity, rich people are rich enough to make it the only option. I don’t care how much the browser needles Google to make theirs better. I care about the fact that Mozilla is always going to be the best option, and the powers that be are succeeding in making it a terrible option.

@djsumdog @alcinnz
If Eich's departure is what made Mozilla go downhill, we can expect Eich's new Brave browser to uphold the principles Mozilla has forgotten, yes?

I think I'll expand on what that design principle I have is: I do not integrate specific websites into my browser, whether it's my own or others. Always allow integrating multiple webservices into homepages, searchboxes, etc rather than just one.

I haven't managed to fully adhear to this yet, and I did make an exception to discourage reliance on YouTube.

But Mozilla doesn't know how else to make enough money to implement a "modern" browser engine. Neither do I.

Might be answering a rhetorical question

You should've asked earlier mario_jump

The main problem is that browser design has always been a loss leader for web-based services. (1500 characters deleted) That doesn't mean you can't find a business model that will work, but having loss leaders in your target market means rethinking fundamentals about markets. In this case, for example, both for profit and nonprofit vectors are saturated, so you'd need a thoroughly postcapitalist approach

Distributing a browser that arrives on the end-user's desktop with a default configuration that approaches decisions they would make for themselves might be easier than attempting to eliminate any bias

But let me know if you're interested in a run down of the core ideas

@yaaps My approach so far is to tackle a poorly addressed niche, illustrating the benefits that have been discarded in the rush for webapps.

But I'm open to all ideas!

You're an artisan. Occupying niches too small for economies of scale is how this precapitalist pattern survives and how it spawns new businesses under capitalism. It relies on a certain amount of privilege in that you need free time, skills, and personal/professional connections to succeed. in addition, the artisan is vulnerable to their own success. Replacing artisans with commodity labor is how capitalism grows

To scale up while maintaining autonomy, you need to establish a worker's collective. That provides a model to distribute income for skilled labor, as needed, without selling equity. Then you can crowd fund, if needed, while building a distributor network

Developing an independent distribution network is how you avoid becoming dependent on key donors. Your browser product will be customizable and unopinionated, with strong privacy defaults, which is not so friendly to most who would use it. Distributors will provide opinionated customizations to end users who share their opinions, without disabling privacy defaults or removing the ability to modify customizations. Your ideal distributors would be those providing community-owned alternatives to profit-driven content platforms - looking at internet access co-ops, user freedom CAPs, student government, clubs and hobby organizations. The general shape of the relationship looks something like the Linux distro marketplace, but maybe a different ratio of financial donations to code contributions going upstream. The idea, however, is to make it easy to repackage your browser with their settings and worthwhile to preserve your user-centric features and contribute

@yaaps I guess the obvious place to start, given the niche I've decided to fill, would be opensource hardware companies like Pine64. Or the distros they choose ship. Could be mutually beneficial.

Once I see if I can get beautiful auditory and TV remote experiences (by partially breaking compatibility), see if that can help them nudge into the phone/smartwatch/TV/etc marketplace.

Just trying to see how I can get from here to there...

@yaaps As for the issue of configurability, it's hard not to deliver that when building browser engines (as opposed browser chrome, like Odysseus). Though I doubt you'd get much from turning off the privacy features, given everything I could *never* afford to implement even if I wanted to.

Rhapsode's design in particular is turning out to be very elegant, and it'll be surprising how much milage you'd get from configuring it's default bookmarks...

@yaaps I will also say: This is a gigantic yak I chose to shave!

It's hard for me to think beyond Hephaestus, and before last week (when I studied Weasyprint, examined line counts, & had a seperate epiphany) that was seeming like a pipedream. I sure hope I get some help by then!

@yaaps @alcinnz Or… we could… stop using a web browser for fucking everything.

When the neos have created a market from nothing, sometimes the solution requires leaving their market, rather than trying to play by the rules they have set.

@cy Absolutely the stance I take!

It's achievable for me to build a web that work absolutely anywhere, it's by no means achievable nor worthwhile for me to build a web that does everything.

I need others to implement what should have long ago been discarded as out-of-scope for the web as native apps.

I'm attempting to change the rules!


@alcinnz @cy
I have strong opinions about what should be on the web - documents. And... my definition of document allows for interactive documents

Reasoning from lesser to greater, if I don't want to run arbitrary code in a web browser to read news, look at grocery sales papers, or report a broken dryer in the apartment laundry room, then I certainly don't want to install a native app for these things. Doubly so if "native" is actually rebranded Chrome with the web app baked in

So I think it's important to have a definition of document that includes forms, but to draw the line at executing arbitrary code or sending any information to the server that outside of that specifically requested of the user. In order to accomplish that, there would need to be a browser engine that is not designed by those working for publishers

As a bonus, such a browser engine might actually be useful to render HTML documents within a native application without the bloat of an engine designed to cope with the web as an execution environment. Thinking ActivityPub client and game clients, here

@yaaps @alcinnz @cy

Right now it looks like there are only two options to, say, buy things from an online store:

1. Use an interactive website of that store
2. Use a native app of that store

And option 2 is more intrusive than option 1. But there's a largely overlooked third option:

3. Have a common protocol for all online stores, and use a native online shopping client of your choice.

@yaaps @alcinnz @cy

Now, option 3 is hard because it requires competing parties to agree on a common protocol.

It is also unattractive to the stores, because it's not a branded experience - the shops cannot influence your UX.

It'd be good for users, but I have no idea how to push self-interested shops to adopt it.

Of course same goes for any other service - chat, ticket booking, etc.

@wolf480pl @yaaps @alcinnz @cy That existed in the past way before the web existed. Shops had some catalogs (in paper) you could read and send them a letter telling which products you wanted.

@ekaitz_zarraga @yaaps @alcinnz @cy
Was the letter in the exact same format regardless of which shop it was?

@wolf480pl @yaaps @alcinnz @cy Not really but you could choose the way you managed the shopping cart lol

@ekaitz_zarraga @wolf480pl @alcinnz @cy
The vendors don't actually need to agree on the format, though that would make it more efficient. Even if Amazon Prime Video, Wal-Mart Vudu, Netflix, and Crunchyroll all had different data formats, a third party app could work as long as the properties were defined and had namespaces. It would be join hell trying to merge their APIs live, but technologically possible top serve a hybrid catalog. If the data was open

Of course capital is dead set on capturing every detail and micromanaging the experience while modern buyers have been conditioned out of an expectation of being able to set hard boundaries, but that's not an intractable problem

@yaaps @ekaitz_zarraga @alcinnz @cy
So kinda like Pidgin / libpurle tries to do with chat... it's an uphill battle, but better than nothing.

>Of course capital is dead set on capturing every detail and micromanaging the experience while modern buyers have been conditioned out of an expectation of being able to set hard boundaries, but that's not an intractable problem

It's not intractable, but the solution is in a different attractor field...

@wolf480pl @yaaps @ekaitz_zarraga @alcinnz That’s a fascinating way to look at it, albeit a mere reframing of the problem. Reality is we can’t move the ball, only change the height of the hills and hope the ball moves the way we want. So all those “fights against violence and oppression” that do “nothing” are changing the hills around slowly, and the ball just isn’t moving yet…


So the key is to do the right “nothing” such that when “everything changes” it goes towards sustainability not a dead smoking rock floating in space.

@wolf480pl @yaaps @cy In the case of online shopping, I can't see how my work excludes option 1.

Sure I'll break many existing ecommerce sites, but I'm planning to allow cookies to be set (only) in response to form submissions. So an "add to cart" button can still work.

Love to have builtin form input for payments...

@cy @yaaps @ekaitz_zarraga @alcinnz
That may be a part of it, but another part is adding an impulse, or a delta of momentum, to the ball, all at once.

Also, let's not focus on the "fight against violence and oppression", which is rather vague and kinda an oxymoron.

My point is, there are forces which you can't control that will affect the situation you want to change, making your battle sometimes uphill, sometimes downhill, effectively trying to pull it to the nearest pit.

@cy @yaaps @ekaitz_zarraga @alcinnz

So what I meant originally, is that there are 2 attractor fields: one with a standardized protocol for doing $X, and another where every provider of $X has its own protocol / API.

In the standardized attractor:
- any branded app restricted to one provider will most likely lose to a generic client program
- clients programs act on behalf of the user
- any provider with proprietary protocol loses customers


@cy @yaaps @ekaitz_zarraga @alcinnz

In the proprietary attractor:
- any generic client has to play cat and mouse, tracking changes in each of N different APIs maintained by its enemies
- branded apps act on behalf of service providers
- a provider has nothing to gain by using a standardized protocol


@cy @yaaps @ekaitz_zarraga @alcinnz

If only we could switch between attractor fields by sending emails into the past...

El Psy Kongroo

@wolf480pl @yaaps @ekaitz_zarraga @alcinnz the ball will set in motion on its own once it’s on a slope. But I do agree the analogy works to give the ball a push now and again, to get it started following the trend. So people seeking change should establish an unstable equilibrium, because their plans to change won’t change, until something happens to get the ball rolling. Like a slope with a sort of ledge…

@wolf480pl @yaaps @ekaitz_zarraga @alcinnz Sending information to the past is just about the only way to cause a technological singularity, so I don’t see that happening any time soon. :p

@alcinnz @wolf480pl @yaaps Well obviously you should expect resistence from every single dishonest ecommerce merchant, but they shouldn’t have enough power and influence to reject your system and all the people who support it, unless there was some kind of wealth disparity or something.

Have a look at IATA's NDC (New Distribution Capability) whose intent is just that - ability to search available "products" (tickets) and sell tickets on 3rd party via airlines NDC API @wolf480pl @yaaps @alcinnz @cy