universal Blinks

[sandys]

the top request for Solana Blink is - universal availability. It should work on all sites.

There is a way - build it into the wootzapp browser we plan to have universal Blink urls like wzblink://bayc-redeem?id=gorillaz

these Blinks will work anywhere. And security taken care of.

Bounty

Wootzapp will fund a bounty for a developer to integrate Blink capability into the wootzapp browser. Bounty Amount: To be announced.

How will work happen

Chromium work is complex. We dont expect you to do this yourself. We will share this work effort with you and help you on this journey. However, there are a few pre-requisites for the bounty applicant.

Pre-requisite

Remember that the work will involve C++ and javascript. The build process is very heavy. This is the interview we usually give our grant and internship applicants - https://pastebin.com/9N0KhvpC . Please make sure you are able to do this before you apply for the bounty.

How to apply

Send an email to people+blink@wootzapp.com with your github profile and the interview solution (from above).

[sandys]

Blinks in Wootzapp proposal

This is the detailed spec for blinks - https://solana.com/docs/advanced/actions however, i will attempt to extract the portions relevant for its implementation in Wootzapp.

Why is this needed ?

The primary focus for the success of blinks is two-fold:

1. universal applicability - and not just on twitter
2. mobile use.

We are not the only ones attempting this. Dialect has client-side SDKs specifically to enable this - https://medium.com/dialect-labs/introducing-the-blinks-client-sdk-8bf0e3474349.

Dialect's Client SDK needs every developer to individually support every site where blinks can be published. For e.g. the default SDK only supports twitter - https://github.com/dialectlabs/blinks/blob/main/src/ext/twitter.tsx#L119

Our attempt with Wootz is to support blinks EVERYWHERE. Our hope is that since we are doing this within the C++ renderer, we will be able to do this 100x faster. Funny thing, Chromium's renderer is also called Blink, so please be careful while reading this proposal.

As our friends in Dialect say...

Our mission is to unfurl the internet

Blink Tech Specs

There are different definitions of Blinks - however, this is ours. Blinks are a standardized way in which "rich rendering" information is associated with any normal, vanilla URL.

For e.g. https://3.land/item/2giCiBwSM6NuL1fYXhxoxtFJr is a normal url with some information about a NFT. The same url has a rich description at https://action.3.land/blink/action/item/2giCiBwSM6NuL1fYXhxoxtFJr2y19FSdyRLyHnMSfrSY . The way that the first url is mapped to the second url is called unfurling.

The standard for unfurling is simple, but presents some challenges in performance.

1. 3.land needs to be registered in a public registry (https://solana.com/docs/advanced/actions#dialect's-actions-registry). This registry is maintained by dialect at "dial.to/register". there are nice security protection available cos of this (static..not runtime), however the main benefit is performance, as we shall describe below.
2. there is a json at the root url that describes the regex patterns. For e.g. https://3.land/actions.json . This is how any url is mapped to the action url.
3. For each url on a page, potentially we need to first find the root actions.json BEFORE we even attempt a unfurl. This kills page load performance and is why the registry is very useful (since it limits the number of urls to attempt a json fetch).
4. Then once the plugin has mapping for urls, it again rescans the urls a second time and unfurls them according to the pattern match.
5. For e.g. for the 3.land example we linked, the relevant tweet is this - https://x.com/Necrosphere21/status/1816438738144330206 . this gets unfurled and rendered.

Wootzapp proposal

• enhance the core inspector functionality in Chromium core to make available loaded urls for unfurling (https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/core/inspector/inspector_dom_agent.cc)
• similar to the patchset here, https://chromium-review.googlesource.com/c/chromium/src/+/5744139 - we will consider implementing this at the traffic filter level for highest performance. However, will need to evaluate if this crashes ad blocking and privacy capabilities. We must take care that privacy and blink rendering dont conflict.
• Long press to unfurl : since we have control over the browser, we are able to implement more interesting user experiences. For example, we can give a long press context menu "Unfurl Blink". This will be a systemwide context menu, so it will work on the whatsapp or instagram app too (which nobody else can do, as long as we get permission from Google Play). This will allow any urls to be unfurled on android.
• Pin a Blink as a widget on Home screen : if we are able to get permission from the Play widget api, we will be able to pin any blink on the home screen as a persistent widget. Again, nothing that anyone else can do.

[nickfrosty]

FYI: Blinks are currently only restricted to twitter due to the desires of browser extension maintainers. Sort of a "walk before we run approach". They can and will be enabled across other websites in the future, not just twitter. One of the concerns is to help ensure users get a good experience of using blinks on other websites. The twitter blinks UI feels relatively native to browsing on normal Twitter. A similar approach should likely be applied to other websites to help ensure good user experience

[sandys]

Hi Nick As you can see in the code snippet (of the extension repo) that I linked above, that each website must be individually supported by path matches. Which is an effort in itself (and probably easier said than done) Unless you do it at chrome-blink rendering time and not post rendering. Here chrome-blink is the c++ renderer and not the solana blink.

On Sun, Aug 4, 2024, 01:10 Nick Frostbutter @.***> wrote:

FYI: Blinks are currently only restricted to twitter due to the desires of browser extension maintainers. Sort of a "walk before we run approach". They can and will be enabled across other websites in the future, not just twitter. One of the concerns is to help ensure users get a good experience of using blinks on other websites. The twitter blinks UI feels relatively native to browsing on normal Twitter. A similar approach should likely be applied to other websites to help ensure good user experience

— Reply to this email directly, view it on GitHub https://github.com/wootzapp/wootz-browser/issues/105#issuecomment-2267114904, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAASYUYIEGIAIDZQRNP5MDTZPUW2PAVCNFSM6AAAAABLQ6SMOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRXGEYTIOJQGQ . You are receiving this because you authored the thread.Message ID: @.***>

[nickfrosty]

It is written that way to accomplish exactly what I described: make the blink appear as if native in twitter. This specific code is not generic to any website, since it is used to render the blink to feel as native as possible on Twitter. Currently, yes each website must be supported individually in an attempt to maximize the UX.

While I think native support for blinks at the Chromium level is super amazing, and can easily be more performant, you still run into the same problem: how does the user interact with a blink? If Chromium was to render the blink natively, vice a chrome extension, the user still needs a good ux in order to complete the entire action lifecycle. If every URL that could be a blink was to render as a blink on the page, same website with same origin links that are blinks would destroy the UI of the website. Example scenario: a website supports blinks at a URL that is displayed on their primary navigation header. If you were to render an interactive blink client where the link is, you would destroy the site's header with even just 1 blink URL in the nav. Now imagine more than one blink URL in the nav

[sandys]

So you raise good points, but the answer is something that is possible at the renderer level.

One way is to highlight the blinks and not render them until user action. E.g make them flow or be highlighted differently.

Alternatively, expose all blinks as a tab layout at the bottom of the screen (so the browser will have tabs layout screen for tabs. But each tab will have a tab layout bar at the bottom for all the blinks).

But all of these are just helpers. The real problem that I'm focused on solving is still performance (which is what I marked in the proposal comment)

The scenario of a page exposing a blink in the header is the prerogative of the page. We run the real risk of being prescriptive on UX and what sites cannot do to handle blinks.

And of course, the elephant in the room is security and malice - the moment you open up blinks to even one more site than twitter, sites will create fake blinks and all the stuff that can be done. To really have universal blinks, you need a browser that can NATIVELY hint to the user that this is a genuine blink.

But there's no gradual rollout here unfortunately. I wish there was - users can't be taught those fine-grained whitelist. But it is either twitter only....or everything else.

On Sun, Aug 4, 2024, 02:21 Nick Frostbutter @.***> wrote:

It is written that way to accomplish exactly what I described: make the blink appear as if native in twitter. This specific code is not generic to any website, since it is used to render the blink to feel as native as possible on Twitter. Currently, yes each website must be supported individually in an attempt to maximize the UX.

While I think native support for blinks at the Chromium level is super amazing, and can easily be more performant, you still run into the same problem: how does the user interact with a blink? If Chromium was to render the blink natively, vice a chrome extension, the user still needs a good ux in order to complete the entire action lifecycle. If every URL that could be a blink was to render as a blink on the page, same website with same origin links that are blinks would destroy the UI of the website. Example scenario: a website supports blinks at a URL that is displayed on their primary navigation header. If you were to render an interactive blink client where the link is, you would destroy the site's header with even just 1 blink URL in the nav. Now imagine more than one blink URL in the nav

— Reply to this email directly, view it on GitHub https://github.com/wootzapp/wootz-browser/issues/105#issuecomment-2267146871, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAASYU7UHW5PVB4SGLONGUTZPU7GXAVCNFSM6AAAAABLQ6SMOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRXGE2DMOBXGE . You are receiving this because you authored the thread.Message ID: @.***>

[sayemzaman]

The Chromium blink engine is responsible for rendering everything we see on the content part of the browser on our display.

The Chromium blink engine is quite stable to my understanding. Devs should be careful when introducing change to the engine as it will affect the main purpose of the browser, viewing contents on the internet. The main purpose of creating so many layers in the chromium engine and keeping blink separate is that you rely on the blink engine to do its job of rendering while you keep making changes on other layers without disruption of rendering.

So my suggestion would be to asses two different paths of implementing this. One is implementing this through the content layer and the other is implementing it in the blink engine.

To my understanding, doing it through the content layer wouldn't greatly affect the performance than doing it on the blink engine. So, trying the unfurl through the Content layer should be the preferred way of implementing this. This needs to be researched first before attempting an implementation on any layer.

Some mentionable classes/objects/locations to start the research from would be Content:webContents, content/renderer, ResourceLoader in blink, blink/renderer.

The idea of rendering b-links at the Chromium engine is fascinating. Still you might run into some performance issue. Eventhough you are fetching json only for the websites found at the registry, you are still checking a registry, fetching some json at least, matching patterns to unfurl and then rendering. So I think it will still have some performance issues or user experience issues. I suppose dev should attempt to do the whole thing asynchronous. Might also have negligible performance issues. Another concerning aspect is security. Devs also need to keep security in mind while working on it.

Usually when Chromium developers mention Chromium engine, they refer to everything below the chrome layer of the architecture. I have used the term "b-link" to refer to the links that can be unfurled. "Blink" is used to refer to the rendering engine in third_party/blink in Chromium.

Some resources: Life of a pixel (Rendering pipeline) How Chromium Displays Web Pages How blink works Content module Multi-process Resource Loading