Yes.

Now just get rid of the server part.

The real missing link between (conventional) static sites and the W3C's social protocols is still static. This post itself already acknowledges the reasons why1.

See also https://news.ycombinator.com/item?id=30862612

Crazy! This underscores how badly Mastodon—and ActivityPub, generally—need to be revved to enable network participation from low-cost (essentially free) static* sites.

* quasi-static, really—in the way that RSS-enabled blogs are generally considered static sites

This term is well-suited for the sort of thing I was going for with S4/BYFOB.

@tomcritchlow's comment about being hobbled by CORS in his attempt to set up an app[1] that is capable of working with his Library JSON is relevant. With a BYFOB "relay" pretty much anyone can get around CORS restrictions (without the intervention of their server administrator). The mechanism of the relay is pretty deserving of the "autonomous" label—perhaps even moreso that Noel's original conception of what Autonomous Data really means...

1. https://library-json-node-2.tomcritchlow.repl.co/library?url=https://tomcritchlow.com/library.json

A sort of "backend on the frontend".

A similar "BYFOB" design principle was the basis for a proposal to bring "Solid[-like] services for static sites" into existence. I submitted this proposal to NLnet in their call for applications for their user-operated Internet fund. It was not accepted.

All in all, despite its own flaws, I think this piece hints at a useful ontology for understanding the nuanced, difficult-to-name, POLP-violating design flaws in stuff like Mastodon/ActivityPub—and why BYFOB/S4 is a better fit, esp. for non-technical people.

https://hypothes.is/search?q=%22black+and+dead+is+all+you+need%22+user:mrcolbyrussell

Feature request (implement something that allows the following): 1. From any page containing a bookmarklet, invoke the user-stored bookmarklet בB 2. Click the bookmarklet on the page that you wish to be able to edit in the Bookmarklet Creator 3. From the window that opens up, navigate to a stored version of the Bookmarklet Creator 4. Invoke bookmarklet בB a second time from within the Bookmarklet Creator

Expected results:

The bookmarklet from step #2 is decoded and populates the Bookmarklet Creator's input.

To discriminate between invocation type II (from step #2) and invocation type IV (from step #4), the Bookmarklet Creator can use an appropriate class (e.g. https://w3id.example.org/bookmarklets/protocol/#code-input) or a meta-based pragma or link relation.

Wordle's spread on social media was enabled in part by its low-tech approach for e.g. sharing scores.

One low-tech approach that could've been used here for data persistence would be to generate and prompt the user to save their latest scorecard in PDF or Word format—only it's not a PDF or Word format, but instead "wordlescore.html" file, albeit one that they are able to save to disk and double click to open all the same. When they need to update their scorecard with today's data, you use window.open to show a page that prompts the user to open their most recent scorecard (using either Ctrl+/Cmd+O, or by navigating to the place where they saved it on disk via bookmark). What's not apparent on sight alone is that their wordlescore.html also contains a JS payload as an inline script. When wordlescore.html is opened, it's able to communicate with the Wordle tab via postMessage to window.opener, request the newest data from the app, and then update wordlescore.html itself as appropriate.

A user on HN asks

So does this automatically fetch every feed URL at intervals in the background as long as you have the browser open?

Two things to observe: people are willing to keep tabs open (esp. for dashboards), and the unreliability of Twitter's website tells us that users will put up with a lot of brokenness.

Here's a thought: use this polling strategy combined with a dashboard combined with a "FCSCORS" (forced client-side CORS). The idea is to embed an iframe from an origin associated with the site to poll, and then use S4/postMessage to communicate with it.

From a neutral, bookmarklet-controlled page (e.g. with about:blank's origin), embed an iframe pointing to some page with the same origin. Force the iframe to open a secondary window (tab) with window.open. A window.opener link now exists between the iframe and the secondayr tab. Set the iframe's location to a page from the desired origin, and then do the same with the secondary tab. A second invocation of the bookmarklet in the secondary tab should be able to use window.opener to get unrestricted access the iframe-loaded document. Use this to install a message handler. The secondary tab can now be destroyed, and the embedding document (dashboard) can merrily communicate with desired origin, with no cooperation necessary (e.g. to enable CORS) by the site operator, and no need for the user to install an add-on.

The question now is, "How common is it for a website operator to set x-frame-options: deny?"

or BYFOB.

With S4, we can do better.

How not to futureproof your work.

Another anti-endorsement for protocols that require this level of power.

Not true anymore.