Blinks for Polkadot ecosystem đź”—

Tech Talk
1

1600Ă—1600 76.1 KB
“Blinks” for Polkadot
1600Ă—1600 76.1 KB

How to enable it? What is actually possible? Exploration, Feedback, TODOs, WIPs and DONEs

Blockchain links, or Blinks for short, are simple links that, when clicked, takes you to a simple mini dapp.

But what if that dapp was brought to you? To the place the link is located, and took away the need for you to click? This is what is called embedded blinks, magical widgets that become embedded mini Dapps, wherever the link is located…

…such as Twitter posts. The user just needs to paste a link into their post and hey presto! The post is transformed into an embedded dapp.

1600Ă—1557 260 KB

Tip some DOT directly from the Twitter post the link was added to…


Vote on a referendum directly from where you procrastinate.

To enable this embedding feature for the polkadot ecosystem, what is required is:

  • TLDR; wallet extension providers will unlock this feature for the ecosystem
  • A “blinks builder” so that anyone can create blinks easily.
  • Setting a (standard) format for polkadot links + Public registry for all blinks
  • Support as an “experimental feature” by all (or at least one of) the wallet extension providers ( talisman, polkadot-js, sub-wallet etc.). Blinks are reliant on browser wallet implementation/support, and can not be viewed/accessed without a browser extension.

We provide a solution for how blinks can work in polkadot, there are of course various ways to implement this.

A key purpose of this post is to inspire intrigue and to suggest controlled experimentation and collaboration with wallet extension providers who already have the distribution across the community.

Telegram group: Here be also polkadot blinks telegram.

read google doc here

What is a blink and how does it work?

There is no “official” definition of a blink, for the sake of defining blinks lets use two definitions:

General “blink” definition:

In general, a blink is a blockchain based link that (just like any link) you can click on, but it takes you to a page that is essentially a dapp which interacts with a blockchain. Just like this link here (I randomly selected it from the https://dial.to site). As you can see the link takes you to a simple page with simple calls to action. This is the general gist of what a blink is.

Magic blink definition (blink + extension = embedded blink = magic blink):

Now imagine that same general blink but now combine it with a browser extension, then the magic and possibility of web3 ensues (see web3 experience visions). The link which is shared into a post becomes an embedded dapp widget that brings web3 to your doorstep, thus, saving you from clicking a link, the link comes to you.

The magic blink works because the extension detects the link as you are scrolling on Twitter, and it modifies your post and injects the widget.

“The sound of injecting stuff into my webpage sounds scary. How do we know it’s safe?”

Well, you already trust your wallet extension provider, Talisman, PJS etc. You rely on them to interact with your private keys, so therefore you would be affording the same trust so they modify your twitter posts. The script injectors are benevolent parties.

The safety and security of the blinks comes down to implementation details, such as: does the wallet extension fetch from an external URL?” If so, what if that URL is compromised? Can the user inject a malicious script tag in the link?

Blinks rely on proper implementation and link sanitation and verification by the browser extension.

But the content itself could be a scam, which involves another layer of verification…

How do we know the blinks will be safe?

Is the blink itself deceptive, such as a button asking for “Donate 1 DOT” but its actually 100 DOT. We can explore how we design our initial version shortly. But, have a look at Solana (Dialect’s) security precautions, such as making sure the blinks content is not a scam with verification levels and a committee that votes on it, albeit centralized and off-chain. Polkadot can perhaps start a little more decentralized and on-chain from the get-go.

Solana Blinks Case study

Blinks(blockchain links) has recently come out of the Solana ecosystem, the goal is to create special links that the browser wallet converts to simple Action like interfaces, where users can easily interact with on-chain applications. So far has the company behind Solana blinks “Dialect labs” verified ~400 different blinks in their public blink registry. Phantom, Backpack and Solflare wallet providers have implemented Blinks support.

Solana Blinks Read more:

https://docs.dialect.to/documentation/actions/actions/building-actions-with-nextjs#multiple-inputs-single-button/

Dial.to provides a preview page for the blinks published using their registry:

1330Ă—1128 222 KB

886Ă—1035 88.4 KB

Solana blinks have an api spec for their blinks, our version will keep pretty close to their metadata spec for easy translation if needed. However….

Solana Actions and Blinks require a centralized server…

Polkadot Blinks will be stored on-chain and are retrieved via light client or rpc call. Decentralised from the get-go.

Proof of concept

@KarimJDDA, product engineer and team lead at Parity, delivered a very useful experiment via his twitter post, where he was able to create a proof of concept,

616Ă—735 113 KB

This is a great initial validation from the Polkadot community

This inspired us (Bagpipes team) interested in bringing about Blinks… after talking to Karim, and the Braille UX (and Bifrost) team at the web3 summit.

For us at Bagpipes it is a “hell yes!”, but it also shifted our perspective in how web3 can play a role in the web2 world, acting as an exoskeleton over web2, rather just an off-ramp from web2 (see Vision for Web3 Experience below)…

How do we make Polkadot Blinks work with Twitter?

Tldr;

Its not with Twitter API, its a more custom and decentralised community driven approach, which requires an extension to make user interface modifications and custom scripting of the web page in question, in this case the twitter website.

Buttons and form fields would be rendered on to posts that contain a “Blink”.

Most Polkadot users have a wallet extension, therefore it can be added in wallet extensions, (Talisman, Nova, Wallet Connect, Subwallet, Polkadot JS, Fear, etc.)

Just Twitter?

Twitter posts can become mini dapps, or any other website, its not limited. The only requirement is those who have a supported extension in their browser.

Scenario:

  • The user is browsing through their x.com feed on their laptop,

  • Their polkadot supported wallet extension is running in their browser.

  • They scroll on to a post, which contains a special link (a blink).

  • The polkadot (or other) extension parses the link and modifies the post to become a web3 widget (embedded app containing fields, buttons and some info.)

Blinks can be used on ANY website and even be embedded in QR codes. Lots of applicable use cases.

# Solution:

“Create a call to action, generate a Blink.”

Anyone can create a blink easily, then share it on twitter.

A Blockchain link is a special link that generates a mini dapp through the extension, or (if they have the extension that supports it) the mini app is rendered into a twitter post.

Blink Builder

A simple user interface for users who want to turn their posts into embedded dapps.

We will start by offering a simple selection of Blink templates for the user to create their twitter post dapp, “Buy Now” and “Vote Now”

Buy Now:

  • The user can customize a “Transfer” to create a fixed price
  • or add a field to allow for custom bids.
  • Buy now button.

Vote Now:

  • the user adds the referendum that they want their twitter audience to vote on.
  • The Vote choice: Aye, Nay, Split, Abstain.
  • We can enforce all of these as a rule for a Blink (not just Aye);
  • Amount to vote and be locked.
  • Vote lock, the multiplier of the vote and corresponding lock up period.
  • Vote Now button

also “Delegate Now”, “Stake Now”, etc… what else shall be prioritised?

There are two main users of Blinks, the creator and the consumer (end-user).

“Magic Blink” Journey

For someone that wants to add a blink to their TwitterX post.

  1. the creator designs the Blink with a Blink Builder. They can choose from a number call-to-actions (Transfer, vote, stake, mint, delegate, mint, etc)

E.g. Select Tip DOT Blink Template, select Recipient address.

1449Ă—1129 173 KB

Initial prototype, where you can design your blink to tip.

  1. Creator generates the blink, and can share it with the community.

  2. Creator adds the blink to a twitter post, and add the link with two emojis in front of the blink, e.g:

    :chains::link:https://blink.bagpipes.io/1

  3. The extension wallet identifies the two emojis and attempts to render the buttons and fields into the post.

We have provided a PoC extension for firefox and chrome that is available here: GitHub - XcmSend/polkadot-extension: Simple browser extension for managing Polkadot and Substrate network accounts in a browser. Allows the signing of extrinsics using these accounts. Also provides a simple interface for compliant extensions for dapps..

  1. Here is the result (example):

1600Ă—1557 260 KB

Note: The extension does not have to fetch from a link even if it is whitelisted, because that still relies on the whitelisted site to not be compromised. Instead the link can either contain encoded data which is parsed by the extension, or the extension interacts with polkadot via light client (or RPC as fall back).

  1. The user clicks on the button “Tip 3 DOT”, which then takes them to either the signer directly or a another page which lets the user choose which wallet they would like to choose. This is dependent on extension implementation (this may be supported soon in PJS).

Bagpipes are enabling Blinks

We’re making it easy to generate a blink, and a wide range of mini-apps.

Just like how Solana has Actions and Blinks, a Bagpipe is an even easier (and more accessible) way for anyone in the community to create their own set of interactions with a blockchain, which can be connected to any use interface as forms with fields and buttons.

1600Ă—667 117 KB

Here is the Bagpipes builder, where you can build a workflow of on-chain and off-chain interactions. The blinks builder is much simpler, but power users can connect them together to make powerful blinks from the bagpipes they design.

We have been working over the past year on making it super simple to create custom interactions with a blockchain with a visual no-code builder. We have been looking at making it simple enough to add widgets and buttons to websites, so that a website owner can turn their website into a DApp without the need for spending developer time.

A bagpipe is a set of actions the user has composed which interacts with the blockchain.

You can generate a blink out of your bagpipe.

WIP: Blinks MVP

on-chain blinks app, link creator, viewer and extension

  • Blink Builder MVP

    • The builder lets you use a few template actions to create the Blink. Starting with transfer which enables tipping and donation, thereafter staking, and many other popular features.

  • Blinks Mini Dapp viewer

    • An app that only connects to the blockchain with no backend server storage. It has local storage.
    • The owner of the Blink shares the link, and a user clicks on it and takes them to a page, which is a mini app.

  • Enabling Embedded mini app for Twitter

    • PJS fork extension:
      • We have forked the polkadot js browser extension in order to get a proof of concept browser wallet that can convert links to blinks, That can be found here

  • The extension only fetches from RPC (or light client) to get the metadata of the blink

  • As a safety feature, the extension will check that the label of the button and the underlying number are the same, if not the blink will render an error.

  • Blink safety approach MVP

    • Blinks will have different security based on their level of verification. The solana approach has so far been to allow the public registry of blinks to manually verify them. Putting the responsibility on the registry servers to verify that no malicious data has been added in the link.
    • To start we will only generation of blinks from users with verified on-chain IDs (Reasonable).
    • For basic safety, only users who have verified ID can generate a blink.

  • Blink on-chain registrar committee can add “audit” the blinks and pass them as humanly verified.

    • the registrar will check for consistencies in the title description.
    • Registrar will verify that link does not contain malicious script tags/obfuscated code.
    • Registrars will block blinks that don’t fit the standard and verify ones that do by providing a whitelist and blacklist. This list can be added on-chain by appending a parsable string via remarkWithEvent, every ~1,000 blocks (TBD).

  • Gather information from Stakeholders:

  • Form working group:

    • Telegram general blinks channel
    • Telegram cross-extension collaboration

TODO: Metadata Spec, Extension Docs

Proposal to all Polkadot extension providers.

Would you be hell-yessing your way to an experimental feature section for “Blinks”? Let’s collaborate on this.

Telegram group: inviting, PJS, Talisman, SubWallet, Fearless (and also Nova even though not an

All major polkadot browser wallets should agree on two things:

What else can be created with “Magic” Blinks?

As a community we can support features that can really bring utility by showing tools through the extensions.

  • Polkadot ID
    • can be assigned to twitter user posts.
  • Chain ratified roles
  • Add labels on to: Ambassadors, marketers, treasury funded projects, collectives, voting DAOs, validators.
  • Any ideas…?
  • Claim NFT with one click
  • Vote on a referendum in OpenGov. Aye or Nay Blink.
  • Delegate Voting power with on click.
  • Custom QR codes
    • Why not print out stickers with QR codes that user can scan to view the simple UI of the application.

There is a risk in not applying Blinks to Polkadot in any form, as other communities adopt this they would have an advantage in engagement and accessible and frictionless interactivity.

Join Telegram: Polkadot Blinks Telegram Telegram: Join Group Chat

Blinks but what else? A vision for Web3 experiences

Group Bliss

In a community bliss experience, we can modify web2 interfaces and create a shared reality that members outside the group cannot see. All underpinned by an objective blockchain secured reality, connected through (mainly) light clients.

Truth not hallucination

Hallucinations cast by malicious demonic entities are protected by the body-polis of the network consensus…

…where we can see things like blinks, but also see added labels from open gov, or perhaps even a fact-checking fairy. When extensions support other ecosystems with shared values, then an even wider bliss experience can be shared.

Web2 is slapped by a web3 suit, an exoskeleton bringing to life on-chain (open gov) verified UX.

501Ă—519 105 KB

Please provide feedback and if you would find it useful to generate blinks for your community then join the telegram group and be the first to use the Blink Builder, as it will be ready to be tested very shortly!

Thanks to:

:point_up:

@Karim KarimJJDA (Parity)

Ben, Alex (Braille), and Thomas Bifrost for inspiration in Web3 Summit.

Iker (Parity)

Thanks for reading…

Written by: Ramsey (Decentration)

Contributor: Filip(Flipchan) @RustSyndicate

Bagpipes Team

17 Likes
2

Super cool! and can be powerful for community building in the eco! :smiley:

6 Likes
3

In my opinion, you’re missing a fundamental point here. On Solana, blinks are a wrapper for actions, as described in their documentation (Actions and Blinks | Solana). These actions must conform to a defined API specification, and blinks simply serve as a way to integrate and represent them.

For this to work effectively, an ecosystem-wide defined API for actions is crucial. Without such a standard (de facto or endorsed but properly specified) pushing for blinks’ adoption is premature, as it would hinder interoperability and scalability.

While it’s convenient to link blockchain actions through social networks, the fact that blinks don’t work on mobile is a significant limitation. Given that the majority of traffic on platforms like X/Twitter comes from mobile, this focus on desktop use seems misplaced.

An API standard is key to ensuring broader ecosystem adoption and long-term utility, beyond a specific ad-hoc visual builder.

Happy to help on the endeavour!

6 Likes
4

Yes! This is true, we put some thought into this under:

The ecosystem would have to decide the prefix of the link, should it be polkadotlink:// or something else. If we take the base format that solana is shipping as the metadata json fields then we can hopefully be backwards compatible with solana blinks, a push needs to be made from browser wallet providers, after the community has agreed on link prefix then the wallet provider needs to implement a regex to detect these links and then query a public registry after the json action data to render.

With a blink integration into Bagpipes as a blink builder, that could enable all pallet calls on pretty much every substrate chain to generate the extrinsic behind the blink mini dapp UI.

2 Likes
5

Happy to help on the endeavour!

Awesome, we’ll share that specification soon enough, just getting an end-to-end thing working. If you want to explore more dm via the telegram group link, you’ll see me there as the admin.

And if you have designed an API spec for the metadata that makes more sense than ours, then we can swap it out. We’re using the Solana actions metadata API as a guideline, but making the blink (link, delivery and fetching) much more on-chain from the get-go. But we can show you what we’ve done and you can say how it can be improved if you like. We are not fixed on the spec, we just want to present something that works and makes sense as V0.

you’re missing a fundamental point here. On Solana, blinks are a wrapper for actions , as described in their documentation (Actions and Blinks | Solana). These actions must conform to a defined API specification, and blinks simply serve as a way to integrate and represent them.

we haven’t actually missed this point. We’ve been working on “actions” for the past year, we call them “bagpipes”, which are a workflow of on-chain and off-action actions that people can design that can create mini dapps. The blinks part is the way it is shared.

Without such a standard (de facto or endorsed but properly specified) pushing for blinks’ adoption is premature, as it would hinder interoperability and scalability.

We’ll share a possible “standard” soon. But i dont think leading with a “standard” and forcing it without feedback and experiments is the only way, or the best way imo. This is why we are sharing the project and engaging with stakeholders at the very beginning. I’m not sure its premature. This is how we’re exploring the matter. Hopefully after some testing via MVP and feedback we’ll have some docs, and an experimental feature that can be PR’d to every extension provider.

Polkassembly are a good example of a project that built something useful and then their API of proposals and comments, etc, became adopted as a standard by Subquare.

Visual builder leveraging a spec that shares metadata on-chain, along with extension is what we’re building, you think it’s premature I’ll tell you why I think it’s not. Because even without embedded blinks enabled, general blinks are mini dapps that anyone can easily build. We believe that’s more overdue. And it’s part of our project’s general mission, to make interacting with blockchains simple and accessible for everyone.

this focus on desktop use seems misplaced

not just desktop, also laptop. Where there’s between 54%- 64% of global use statista, 2024.

64% is not exactly misplaced focus. you could say the same thing about most dApps, which are designed to work on desktop, with an extension that links to a QR where they can sign with their mobile app.

Re: Blinks for mobile apps. we’re not holding the breath for blinks injected into Twitter app on mobile! perhaps more of realistic question is how to enable and best leverage deep links. If the user clicks a deep link that can redirect them to their mobile wallet. But I think makes sense to focus on laptop version. Because that’s where (embedded) blinks can work with extension support. While the fallback being a link to a website, people can go to when they are on their laptop (or Desktop).

There is a lot of power in just normal non-embedded blinks, so while i appreciate your concern for an api standard, we also see a need for easy creation of Dapps (which is what the blink is linking to) by a wider set of non-technical users.

2 Likes
6

Here is a tweet thread summary for Blinks for Polkadot.

1 Like
7

Excellent stuff team!

I’m quite excited to see this materialize and cannot wait to use it as well as hear feedback from how customers and users interact with it - it’s all that ultimately matters. I’m very happy you decided to work on this and glad my tiny weekend demos inspire more and more people to develop things. I hope these sort of products attract more people to be exposed to Polkadot by either knowing that these things are possible on Polkadot or by integrating other ecosystems in a successful product that has Polkadot at its center or as the default option. Keep building and creating tangible things no matter the headwinds.

And by the way, mobile blinks is ~ solved, the trick for that is to develop an application that leverages iOS accessibility features to inject frames into running apps, check this out. :mage: I do think though that even if it remains a small trick for the mobile part (and perhaps a dangerous one if you read into it a bit more), it can still make for a great demonstrator especially for a more skeptical audience.
However for the mobile part, I would see a collaboration with our beloved ecosystem mobile wallets to be the pragmatic path ahead instead of setting course on creating your own mobile app, at least to explore making a simple proof of concept. I would have showcased a demo but I cannot get my XCode project to compile :disguised_face:

Good luck!

5 Likes
8

Thanks Karim!

cannot wait to use it as well as hear feedback from how customers and users interact with it - it’s all that ultimately matters.

100%. will have live working product for “general blink” soon, where basically blink creators can easily create a blink and share it as a link in their posts. Then the “magic (embedded) blink” will surely follow after the first extension(s) to support.

hey the link you shared was very interesting, i had to ask how he did it, as it just seemed too magic.

Screenshot 2024-09-13 at 08.57.05
so the app interacts with Twitter if accessibility settings are enabled.

a) The above solution is a little less seamless than laptop version, because i think it is overlaying labels rather than re-rendering the code.

b) I suppose another mobile idea is that if you run twitter within e.g. the Nova app explorer, then that can customise the site.

But both a) and b) come with trade-offs.

Another approach is if Twitter become like MySpace and support a wide variety of customisation, but then that won’t be permissionless, so its less web3.

I do think though that even if it remains a small trick for the mobile part (and perhaps a dangerous one if you read into it a bit more), it can still make for a great demonstrator especially for a more skeptical audience.

i suppose some skeptics would still question when demonstrating to them their own existence… but what would be the safety issues that we cannot mitigate? I think the solution to almost all things is light client :stuck_out_tongue:

i wonder if Nova @AntonTheDay7 @Leemo would support an experimental feature like this?

3 Likes
9

So exciting to see our discussion and idea come to life in such a short time!
Gj guys :partying_face: :heart_eyes:

Joining the Telegram group now - hopefully we can continue helping steer this into a marketable product :smile:

2 Likes
10

I think you’re right on the chain interaction side, but I’m more worried about the device: an application that can read anything on your screen and do whatever with it is a very tough sell. That’s essentially what the accessibility features enable, although I admit I’m not an expert there so there could be some mitigation possible.

1 Like
11

i see what you mean, i imagine for apple phones that accessibility privileges can be specified rather than for everything. but yes its all very hacky and experimental, much more so than an extension re-rendering web pages :stuck_out_tongue:

1 Like
12

MVP metadata example would look something like this (rough sketch, and would have less stuff there):

this metadata will be stored on-chain, and the intitial blink for our MVP would look something like this:

⛓🔗<URL>/actions=<chainName>:<blockNumber>:<encodedCallHash>

and soon docs ofc

1 Like
13

Here’s how I think we can approach this:

The server API model used in binks/actions is fundamentally insecure. This is because, even if the API endpoint is registered and verified, the backend logic generating the data to be signed can be changed at any time, leading to security vulnerabilities. Additionally, its capabilities are very limited, as it only allows for one-shot interactions that must be completed in a single transaction.

We can agree that security is provided by the wallet, as well as the rendering of a dynamic mini-UI embedded in the page. So, wouldn’t it make more sense to remove the server API entirely? Instead, wallets could support a subset language (similar to AMP for emails) that allows injecting a Polkadot API provider (along with whitelisted libraries) and embedding a dynamic mini-dapp in this way. URLs could include a hash for integrity checking during unfurling, making a registry of audited mini-dapps more secure. These mini-dapps could have rich interactions and context leveraging domain-specific intent/actions libraries reusable across the ecosystem.

Of course, this is just a pointer on a potential approach IMO worth exploring, but maybe now is not the best moment. If validated needs a lot of care to make it a reality that can be adopted, and there’re a lot of foundations that are being laid out and require focus and substantial effort at an ecosystem level.

14

Sir… I’m not sure how you want me to respond. If you read the original forum post, you will find that’s exactly the plan. To remove servers, and go on-chain. And in the message you are replying to, I just shared the URL that contains the chain name, blocknumber and encoded call hash. So it would make sense to actually read what I’ve written, acknowledge what I wrote, then comment after.

1 Like
15

Love this!

1 Like
16

I guess that you’re not understanding what I wrote above.

The point is to remove the API server (i.e. bagpipes) from the equation and serve a mini-dapp that don’t connect to any API server backend and the content (i.e. the source code of the app not a metadata to interact with remote servers) can be checked, having all the logic client side.

Do you got it?

17

yes exactly, you got the right idea, the blinks app (we’re building) is fully client side, and it will interact with blinks stored on-chain. completely serverless.

18

In the example of metadata that you shared:

"links": {
            "actions": [
                {
                    "label": "stake",
                    "href": "/api/staking/bond"

Where’s is this link action supposed to connect to pass the parameters and the account? To the bagpipes API that will return the transaction to be signed, right?

This is what I’m saying to be replaced by client-side script logic. And in fact to remove the whole metadata thing and serve something equivalent to AMP email but without the possibility to connect to remote APIs…

Using the below diagram as orientation, your approach suggests to move the metadata GET request on-chain,e.g via system remarks, and the POST request through Bagpipes.

What I’m suggesting is to serve a mini-dapp to replace completely the Action Provider (written in a subset language with only client-side logic) where the source code can be stored on any decentralised storage and retrieved.

1000012501
10000125011600Ă—869 55.1 KB

2 Likes
19

Thanks for the AMP link will check it.

Where’s is this link action supposed to connect to pass the parameters and the account? To the bagpipes API that will return the transaction to be signed, right?

no this is just the solana metadata, there is no bagpipes api being used in this. the links.actions are parsed by the client to create the mini dapp interface. adding a stake form.

we’re storing the metadata on-chain and then fetching the metadata from the chain, ideally with a light client, but falling back to RPC. No “APIs”. no middleware.

You’re right, the metadata data structure looks like solana, but as i said i just shared you a very rough draft piece of metadata that will go on-chain, here is a link of it on-chain as a system remark…

The URL of the blink for V0 looks something like this:

⛓🔗<URL>/actions=<chainName>:<blockNumber>:<encodedCallHash>

so we can use this link to fetch the metadata and then render the app.

so the answer to your suggestion is that, we are indeed going with a fully on-chain approach.

20

Here’s my non-techie take on it.

In principle, this is exactly the way to go: meet the users where they already are. The mobile-first approach is a given.

mobile-use
mobile-use1578Ă—887 93.6 KB

Whatever route is chosen, it should work for people outside of the ecosystem primarily. They won’t install Nova wallet first. It has to work on their own X mobile app without them having to enable any features or settings. Also, the blink should have a view that is shown to users who, for some reason, cannot see the content as intended (perhaps just a link to navigate elsewhere).

This does open a lot of questions regarding security. Scammers would take use of it, for sure. Gotta make it so that it doesn’t ruin our reputation.

It also reminds me of the hugely popular social media apps that were developed on top of Facebook, LinkedIn etc back in the day, and that died practically overnight when the social media giants made their APIs more restrictive.

If we can really do this things permissionlessly and it’s not dependent on the whims of Elon Musk, then go for it.

2 Likes