NIP-22: Smart Widgets – interactive components

[Seddik-Boukhalfa]

This NIP introduces the concept of Smart Widgets for Nostr clients. Smart Widgets are customizable, interactive components that can be embedded within Nostr events. These widgets allow users and developers to create rich, dynamic content that enhances the user experience. This proposal outlines the structure, implementation, and potential use cases of Smart Widgets within the Nostr protocol.

[erskingardner]

with or without alpha?

[Seddik-Boukhalfa]

It's a hex code, so yes, it can contain alpha.

[dskvr]

FYI, NIP-22 was taken by #1434

[vitorpamplona]

Don't worry too much about NIP numbers, they always change before the merge anyway.

[staab]

This makes sense, is there a library that can be used to parse these?

[dtonon]

It can be set to mono layout (type 1), which includes a default left_side, or to duo layout (type 2), which features both left_side and right_side.

Has responsiveness (e.g. rendering on phones) been considered?
I would probably simply number the blocks and let the client render them according with the screen size (horizontal / vertical) and language (LTR / RTL). This of course requires that who designs the blocks does not make the order binding, such as with an image that contains a reference to the direction of the other block.

[Seddik-Boukhalfa]

This makes sense, is there a library that can be used to parse these?

We are yet to submit a library that handle the parsing of the smart widgets. Although, any client can do the implementation as the structuration of the smart widgets is straight forward and it only requires consideration of some specifications on each client.

[Seddik-Boukhalfa]

It can be set to mono layout (type 1), which includes a default left_side, or to duo layout (type 2), which features both left_side and right_side.

Has responsiveness (e.g. rendering on phones) been considered? I would probably simply number the blocks and let the client render them according with the screen size (horizontal / vertical) and language (LTR / RTL). This of course requires that who designs the blocks does not make the order binding, such as with an image that contains a reference to the direction of the other block.

The smart widgets are responsive on Mobile devices as well yes since the structure allows for a predefined layout of 1 or 2 at max which is simple and straight forward (check out YakiHonne).

As per your suggestion, it makes sense to ensure total flexibility and responsiveness, it was considered in the early design of the smart widgets, but we came up with the current structure as it keeps the smart widgets follow specific guidelines when it comes to each element positioning and space taken (using divisions) which ensures that the smart widgets have the same structure across different devices.

[pablof7z]

This is like a more limited form of HTML and, at the same time, requires a custom rendering engine that will forever be a moving target.

Instead of inventing a new documentation and styling specs we should just reuse the existing ones or forego layouts+styling, again, specially because this will be a widely moving target when it meets users' wishes.

[dtonon]

but we came up with the current structure as it keeps the smart widgets follow specific guidelines when it comes to each element positioning and space taken

This is ok. I just refers to the key names, they seem misleading to me.

[dtonon]

Btw, I agree with Pablo, introducing a new rendering engine is a huge burdensome for clients, we risk ending up with long notes with missing parts, making the user experience inconsistent.
Html + css could seem like the more obvious choice, but again, this is a problem for native clients that would be forced to add a webview.

If I didn't misunderstand something, it seems that the gain will be just having a two-column structure, when today more of 85%+ of users (unfortunately) use a smartphone that lines up all the content. Thus, it is only a minimal aesthetic benefit, excluding polling, which, however, is only the inclusion of an external event with a background color.

I would actually vote for this approach: just include events with the standard nostr:xxxx syntax, so clients that don't support the rendering can simply redirect to another app to show the embedded content.

[melvincarvalho]

+1 will implement. Much needed next gen functionality. Given that the NIP is optional, clients can choose whether they want to render smart widgets or not. Users can also vote with their notes, if they like them.

[vir2alexport]

Agree with Pablo and I think you can use data uri scheme for this.

Here's a simple demonstration:

<!DOCTYPE html>
<html lang="en">
<head>
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<meta http-equiv="Cache-control" content="public">
	<title>DATA URI TEST</title>
	<link rel="icon" type="image/x-icon" href="#">
	<script>
		let content = '<svg viewBox="0 0 10 5" xmlns="http://www.w3.org/2000/svg"><a href="https://relays.xport.top" target="_blank"><rect width="10" height="5"><animate attributeName="rx" values="0;5;0" dur="2s" repeatCount="indefinite" /></rect></a></svg>';
		window.addEventListener("load", function(){
			document.body.innerHTML = content;
		});
	</script>
</head>
<body>
	
</body>
</html>

[Seddik-Boukhalfa]

This is like a more limited form of HTML and, at the same time, requires a custom rendering engine that will forever be a moving target.

Instead of inventing a new documentation and styling specs we should just reuse the existing ones or forego layouts+styling, again, specially because this will be a widely moving target when it meets users' wishes.

Can you elaborate more on this? What exactly do you mean by reusing existing ones or forego layouts+styling? Are you referring to a more abstract approach when it comes to defining the smart widgets?

[Seddik-Boukhalfa]

Btw, I agree with Pablo, introducing a new rendering engine is a huge burdensome for clients, we risk ending up with long notes with missing parts, making the user experience inconsistent. Html + css could seem like the more obvious choice, but again, this is a problem for native clients that would be forced to add a webview.

If I didn't misunderstand something, it seems that the gain will be just having a two-column structure, when today more of 85%+ of users (unfortunately) use a smartphone that lines up all the content. Thus, it is only a minimal aesthetic benefit, excluding polling, which, however, is only the inclusion of an external event with a background color.

I would actually vote for this approach: just include events with the standard nostr:xxxx syntax, so clients that don't support the rendering can simply redirect to another app to show the embedded content.

I would say that the smart widgets definition is simple and easy to adopt, the structure follows specific guidelines and uses a well defined elements, which ensures an appropriate visualization across different devices.

Adopting web aspect in this regard is not a favorable idea as it enforces natives clients to add a Webview as you said, which is not that great of an idea.

And since the smart widgets are addressable events, yes they can be attached in notes or articles (nostr:naddr1), in which other clients that implement smart widgets can render them, if not, it will be forwarded to clients who do so.

[Seddik-Boukhalfa]

Agree with Pablo and I think you can use data uri scheme for this.

Here's a simple demonstration:

<!DOCTYPE html>
<html lang="en">
<head>
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<meta http-equiv="Cache-control" content="public">
	<title>DATA URI TEST</title>
	<link rel="icon" type="image/x-icon" href="#">
	<script>
		let content = '<svg viewBox="0 0 10 5" xmlns="http://www.w3.org/2000/svg"><a href="https://relays.xport.top" target="_blank"><rect width="10" height="5"><animate attributeName="rx" values="0;5;0" dur="2s" repeatCount="indefinite" /></rect></a></svg>';
		window.addEventListener("load", function(){
			document.body.innerHTML = content;
		});
	</script>
</head>
<body>
	
</body>
</html>

This adoption is limited to web clients only. How exactly do you intend to run this on native mobile clients?

[staab]

My two cents is that HTML is too powerful and complex, and markdown/asciidoc are too limited for something like this. So I don't know what the alternative to the bespoke markup format being proposed might be, but if one exists we should use that instead of making a new one up.

[Seddik-Boukhalfa]

My two cents is that HTML is too powerful and complex, and markdown/asciidoc are too limited for something like this. So I don't know what the alternative to the bespoke markup format being proposed might be, but if one exists we should use that instead of making a new one up.

I will be glad to hear any suggestions that will lead to a more optimized approach of defining smart widgets, if such approach exists it's very welcome to be discussed, if not, with the contribution of the community, we might be on the doorstep of introducing something new that can be widely adopted.

[vir2alexport]

This adoption is limited to web clients only. How exactly do you intend to run this on native mobile clients?

All I suggest is using data uri scheme instead of <smart_widget_stringified_json>, so content from my example above is event.content that might look like this

content = {
   mimeType: 'image/svg+xml',
   data: '<svg viewBox="0 0 10 5" xmlns="http://www.w3.org/2000/svg"><a href="https://relays.xport.top" target="_blank"><rect width="10" height="5"><animate attributeName="rx" values="0;5;0" dur="2s" repeatCount="indefinite" /></rect></a></svg>'
}

and then you can sanitize it with DOMParser

if you want just image then

<img src='"data:"+ content.mimeType +","+ content.data +"' />

and if you need links buttons click images etc then simply

element.innerHTML = event.content.data;

[Seddik-Boukhalfa]

This adoption is limited to web clients only. How exactly do you intend to run this on native mobile clients?

All I suggest is using data uri scheme instead of <smart_widget_stringified_json>, so content from my example above is event.content that might look like this

content = {
   mimeType: 'image/svg+xml',
   data: '<svg viewBox="0 0 10 5" xmlns="http://www.w3.org/2000/svg"><a href="https://relays.xport.top" target="_blank"><rect width="10" height="5"><animate attributeName="rx" values="0;5;0" dur="2s" repeatCount="indefinite" /></rect></a></svg>'
}

and then you can sanitize it with DOMParser

if you want just image then

<img src='"data:"+ content.mimeType +","+ content.data +"' />

and if you need links buttons click images etc then simply

element.innerHTML = event.content.data;

I understand your proposition, it would make more sense if it's only destined for web based clients, how can this approach be handled in native mobile client? Because smart widgets with its abstract structure can be implemented on both.

[vir2alexport]

I understand your proposition, it would make more sense if it's only destined for web based clients, how can this approach be handled in native mobile client? Because smart widgets with its abstract structure can be implemented on both.

You don't have to use some xml like content that must be parsed. But if you do then use Webview or parse it with some kind of xml parser.

Have a look here #1468 looks much better that way imo

[Seddik-Boukhalfa]

I understand your proposition, it would make more sense if it's only destined for web based clients, how can this approach be handled in native mobile client? Because smart widgets with its abstract structure can be implemented on both.

You don't have to use some xml like content that must be parsed. But if you do then use Webview or parse it with some kind of xml parser.

Have a look here #1468 looks much better that way imo

This proves what was mentioned in the discussion above, using Webviews in native mobile clients is a poor idea which should not be considered as it has a lot of implications. Your approach is not as abstract to allow for cross-platform use as Smart widget introduces.

[vir2alexport]

This proves what was mentioned in the discussion above, using Webviews in native mobile clients is a poor idea which should not be considered as it has a lot of implications. Your approach is not as abstract to allow for cross-platform use as Smart widget introduces.

I see.

In your case, you can use application/json MIME type and JSON stringified content.

[NielLiesmons]

using Webviews in native mobile clients is a poor idea which should not be considered as it has a lot of implications

What implications exactly?
Seems like a more or less inevitable way forward if we want things like Stories and Widgets with actual functionailty. Webview might have a wide danger zone to it, but already a lot less if you limit comms/API calls to Nostr only. I'm very interested in what other limits we can put on HTML to make it accepotable.

I don't really understand what your use case is here. The only things your widgets allow you to do are things users can already do anyway in posts/articles (links, videos, images, polls, ...). I don't think adding borders and colours to link buttons are worth parsing an entirely new markup language.

What I need is this:
https://njump.me/naddr1qvzqqqrcvgpzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qyt8wumn8ghj7mnfv4kzumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezumrpdejz7qqddpuhqetjdehhgefdde5hqyzzlyx

I don't know if that overlaps with your goals. If it does, hit me up.

[Darecjo]

Seems like a more or less inevitable way forward if we want things like Stories and Widgets with actual functionailty. Webview might have a wide danger zone to it, but already a lot less if you limit comms/API calls to Nostr only. I'm very interested in what other limits we can put on HTML to make it accepotable.

HTML has always been avoidable since it has implications to the mobile apps devs and more. For such reason and others, you are seeing a stringified json with new abstract properties that clients devs can depend on to render the widgets.

I don't really understand what your use case is here. The only things your widgets allow you to do are things users can already do anyway in posts/articles (links, videos, images, polls, ...). I don't think adding borders and colours to link buttons are worth parsing an entirely new markup language.

In normal cases like you are saying, users can't use customized buttons with customized nostr profiles for displaying or zapping, or let's just say customized POSTS in general. In addition, this is just the initial proposal and it is heavily OPENED for changes and improvements no matter how they look like. So rather than dispatching the same concept as bread crumbs all over proposals, I think it's better to minimize it in one place and work on improving things up that's all what I'm saying.

What I need is this:
https://njump.me/naddr1qvzqqqrcvgpzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qyt8wumn8ghj7mnfv4kzumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezumrpdejz7qqddpuhqetjdehhgefdde5hqyzzlyx

And this can be done with the implementation in here, perhaps some minor specifications are still missing or not improved yet, due to the load of complications these widgets has that's all.

[fiatjaf]

I like the idea, but I think we can't have a design language inside events.

It would be much better to just define a program that takes inputs and emit outputs, then let the host app determine how to display these in the UI.

For example, a widget could declare it expects a pubkey, then the app would display a dropdown of Nostr profiles for the user to choose; or the widget could declare that it expects an amount and current user's pubkey, and the app would display a numeric field for the amount and a confirmation button prompting the user to authorize sharing its own pubkey.

The widget itself could be a little WASM program that would be able to call some Nostr-specific functions (defined in the spec) using the inputs, then emit different kinds of labeled outputs, such as a single value, a Nostr entity link, an image URL, a URL or a table or list of values. Then again the app would display these somehow.

I don't know, I've never implemented this, so I am just imagining things.

[Darecjo]

but I think we can't have a design language inside events.

Yes, after the first launch we are also planning to switching this off.

For example, a widget could declare it expects a pubkey, then the app would display a dropdown of Nostr profiles for the user to choose; or the widget could declare that it expects an amount and current user's pubkey, and the app would display a numeric field for the amount and a confirmation button prompting the user to authorize sharing its own pubkey.

These kind of use cases are existed, however as you said they affected by the design and not obvious enough.

The widget itself could be a little WASM program that would be able to call some Nostr-specific functions (defined in the spec) using the inputs, then emit different kinds of labeled outputs, such as a single value, a Nostr entity link, an image URL, a URL or a table or list of values. Then again the app would display these somehow.

We will see how things will go with this.

I don't know, I've never implemented this, so I am just imagining things.

Much appreciated, thanks.

[melvincarvalho]

In the Solid project (https://solidproject.org/), we’ve been rolling out "Smart Widgets" (also called "Solid Panes"), which have really taken off among developers—both in terms of creativity and usability. The project is gaining momentum with new contributors joining (on a related note, I’m also working on Nostr auth).

This PR has become the most upvoted in Nostr’s history. Could we consider merging it, even if it's not perfect yet? It could improve based on what we learn from the first rollout.

[sanjay-shah]

This PR has become the most upvoted in Nostr’s history. Could we consider merging it, even if it's not perfect yet? It could improve based on what we learn from the first rollout.

Got directed to this PR by one of our users at Predyx.

I'm very interested in seeing this PR merged. We plan to bring our prediction markets to nostr, and I think Smart Widgets would be a good start for us.

[vitorpamplona]

Merging requires 2+ clients that FULLY implement the PR. How many implementations of this PR exist today in production? I assume YakiHonne implements all the features described. Is there anyone else?

@Seddik-Boukhalfa can probably edit the first post with an implementation tracker to help us out.

[Darecjo]

@Seddik-Boukhalfa can probably edit the first post with an implementation tracker to help us out.

it is already under this issue with nostrability: nostrability/nostrability#99