Status widget/plugins/dApps as a way to iterate faster

Feature requests
,
1

The concept of dApps/widget/plugins in Status app is not new and precedes me.

The most recent attempt was done by the Logos Innovation Lab in the form of “Waku Play”. A widget system that can be included in the web chat app they created to enable sharing a member’s location or splitting bills.

Another previous attempt can be found here: Status Chat Widget - An Embeddable Status Chat Widget for your website

Description

Here is an attempt to describe exactly what we are talking about. I do not have a fully formed idea on how it would like so please bear with me.

Very similar to Farcaster Frames: exposing an API to enable anyone to build mini-dApp that can be loaded in a group chat (for Facaster it’s embedded in a “cast” on the feed).

This could also be similar to a Telegram bot, but without the need to host a Telegram bot somewhere.

The API should enable:

  • display text in group chat to all or some members
  • display images in group chat to all or some members
  • display a button to all or some members
  • accept some input: text, amounts

Pushing a button may lead to:

  • send a message in the group chat, which would be “hidden” in the chat but consumed by the widget instance of other members
  • call a specific wallet action such as
    • do a specific transaction: fixed amount to fixed recipient (eg pay another member)
    • do an open transaction: buy token X, but the amount and the source token for the swap remains open

Examples

Such API could enable the following features:

Multisig wallet

Group chat for owners of a multisig wallet.

Widget allows deployment of multisig wallet where all group members are owner.
→ button to enable a wallet call, which is a multisig contract deployment prefilled with eth addresses of group members.

Transaction can be discussed in group chat (normal group chat usage).

Transaction can be initiated in group chat: button to start transaction, lead to wallet action where recipient and amount can be specified.
Initiated transaction (first signature) is then sent in group chat - message is interpreted by the widget, show to chat as specifically formatted text.

transaction can be signed: when widget receives (by accessing messages in group chat) transaction proposal, shows button to other users to sign it.

Split bill

Widget could accept amount and text for users to input their expenses
Then when settling, widget shows button to initiate wallet action to settle expenses

Games/betting

Any games can be built “over Waku” by just using the available API. Making building on Waku more accessible.

Games could be tied to some betting (eg lets play poker between friends) that leads to wallet actions.

It can also lead to prediction market/bet between friend where again, the bet is driven from the chat.

Copy my trades

Defi group chat.

A member can share all their meme coins trades: API allows a member to expose events/history on a given address.

Any member can “buy the same”: the event have a “do swap” button displayed to other members that enable them to do a swap and buy same memecoin.

Marketplace

Similar to the community curation dapp, a marketplace could be created to enable developers to list their widgets. SNT could play a role here, same as community curation.

Biggest mover

Again defi group, the widget can pull data from one or several exchange and provide live market data in the chat. Such as biggest 24 hrs movers.
Button can be displayed to swap/buy those movers, calling for wallet action.

Experimenting Status features

While onboarding widget developers may not be a high priority. iterating on new wallets features, and leveraging chat seem to be one.

Such an API/widget system could be consumed internally to iterate faster on wallet/dapp cross-features. Enabling users to install experimental widgets, and deploying new widgets (ie features) without being locked in the status app release cycle.

It may also be easier to trash/deprecate widgets that do not prove attractive, without cluttering the Status codebase or having to delete from it.

This may be an interesting up-front investment to iterate faster on new features.

Widgets that are successful and popular could become embedded and “shipped” or “installed” by default. With a preferential spot in the potential marketplace.

Conclusion

Security model has to be well thought and I don’t have all engineering solutions. Building an API that can only be used by “approved developers” (ie Status CCs) first may allow a progressive roll out until security is figured out, while enabling fast iteration on core Status app features.

As a Waku contributor, this is also an exciting proposal. As it would enable developers to “build on Waku” much more easily and faster, leveraging what chat protocols bring: identity, group chat, etc.

2

yes i cant cheer this proposal on enough. given that the team has been working on status network, the whole point of which seems to be onboarding cryptoapps for status, i have to imagine they already must be at some advanced stage internally on the work required for this proposal? at the very least i know they are running a discord bridge bot and a spiffworkflow chatbot so they know how to make it work in some basic form. it would be great if another example could be added in that linked cmd folder of status-go that uses more of the status chat features so more adventurous status users/community owners could experiment with say welcome bots. or even simple chat games like tic-tac-toe where you only interact with a bot by mentioning them in a chat and saying your next moves. once you have such boilerplates available users can start getting creative already with low-stake stuff before the team has figured out a polished and secure api/sdk. @cyp thots?

1 Like
3

Other widget idea. Everyone is talking about AI Agent:

  • Have a chat with your AI agent, can include prompt around market predictions
  • AI agent (on training wheels) can submit tx to run (eg buy meme coin) in the chat, press button to approve and sign tx.
2 Likes
4

Expanding on this idea.

Let’s go down the bot architecture. A main difference to telegram is that the bot is local (at least at first).

One can install a bot by adding it as a special contact. The bot would be linked to a specific piece of code.

Many security assumptions, but we should see it as a browser extension. Once the bot is installed, you have code running locally for this bot.

At first, interaction can be only one-to-one and local. Meaning no messages sent over Waku, and potentially no direct internet access. Or only very restricted access to enable some use case while keeping it secure.

Later, a bot could be added to a group chat. This means that users would need to install the bot locally and the bot would get access to some messages in the chat, and send messages over the wire.

A bit difference from Farcaster Frames is that while some data can fetched from a remote server, the code and logic should be installed locally once.

API

The bot code should be able to access an API to call for specific actions. This should be defined similarly to the Chrome extension API (not saying same API, but definitely need some inspiration).

For example

display(text: string, buttons: { text: string, action: Action }[])

Plain text message is displayed in the chat as a message coming from the bot.
There can be action buttons under the text, similar to Farcaster frames. The possible actions are:

  • {type: 'execute', text: "tap here to execute some code", function: function_name(args) }: run a specific function define in the bot code (ie, wizard flow, to interact with the bot)
  • { type: 'wallet', text: "send token to friend", action: wallet_action }: a specific wallet action, that redirects to the wallet (ie, to send some token to a user)

alarms

Similar to Google Extensions API to schedule code

register(handle: string)

Register this bot to parse messages sent over the wire.
This authorize the bot to read messages in the group chat they are invited to. if the messages are tagged with handle.

It also means that any message sent by the bot in a group chat, has to be tagged with handle.

If a bot has register handle in the group chat, and a message comes with it, then the message may be hidden to the user and just processed by the bot, who may display something different by processing the inbound message.

It also means that if no bot is registered in the chat, then the raw message could be displayed, prompting the user that it may be interesting to “invite” a bot in this chat to handle the message.

In addition, this or a different api should allow the bot to read local messages that are a replied to its own or where it is tagged.

It also means backward compatibility (these are just regular messages, but the person tag is a bot)

sendMessage

A message is sent in the group chat, this message is sent over Waku and tagged with handle to let local bot instances of recipients process the message.

More examples

Consume RSS feed

Consume a remote RSS feed to display in the chat room.

// Function called after user has installed the bot
init() {
 // Display a message with one button to schedule the feed.
  display(
  // status api is exposed via `status` object
    status.display("Do you want to start receivings news about x?",
      {type: "execute", text: "Subscribe to feed", function: scheduleRss })
}

// schedule RSS feed retrieve
scheduleRss() {
  status.alarms.create('fetchSubscription', {delayInMinutes: 1, periodInMinutes: 60 })
}

// React to the alarm
status.alarms.onAlarm.addListener((alarm) => 
{
  if (alarm.name === "fetchSubscription") {
   const response = await fetch ("http://myrssfeed")
   const json = await response.json()
   const lastEntry = json.entries.pop()
   // Display to the user the last entry of the feed
   display(lastEntry.body)
  }
})

Request money to friend

Alice and Bob have a 1:1 chat. They both install the “money” bot to the chat.

Here is the bot code

// Bot setup
init() {
  // Register to listen to messages

  status.register("money")
  status.register.onMessage("message" => {
    // Alice can send in chat "@money request 10SNT"
    // Or a message sent over the wire tagged for the bot is received (json format)
    const [action, data] = parseMessage(message)
    if (action === "localRequest") {
      display("Confirm requesting friend for ${data.amount}",
        [{ type: "execute", text: "Yes", function: request(data.amount)},
         { type: "execute", text: "No", function: abortRequest}])
    } else if (action === "remoteRequest") {
       const [recipient, amount] = action.data
       display ("${recipient} requested ${amount}",
         [{ type: "wallet", text: "Send", action: "eth:0.5eth:0x..."},
         { type: "execute", text: "No", function: rejectRequest}])    
    } 
  })
}

request(amount) {
  // Sends a message over the wire to be received by recipient's bot
  status.sendMessage("@${handle} {type: "request", amount: amount, recipient: 0x... //chat key}")
}

Additional Notes

I hope this provide a more concrete example on how the widget idea could be executed.

Permissions to access specific API should also be asked/given when installing an app.

A first approach would be to not open the “bots” to other developers, but only have bots installed by the Status app. Removing from first scope the ability to install/uninstall a bot etc and trimming the scope as much as possible for a PoC and one first example so that only part of the API can be implemented at first, and focus on local bots first, where no messages over the wire are sent.

The UX is just a proposal. Buttons are interesting, especially for wallet action. But it may be easier to just send commands by tagging or replying to the bot (or only have buttons for wallet actions, and the rest being handled via text commands).

Of course, the bot code is just an example and incomplete.

Links

1 Like
5

Other example

Social Recovery Wallet

  1. Discuss with local bot to setup a new wallet with social recovery
  2. Select 5 contacts to give access to the bot. setting up a 3 out of 5 guardian threshold
  3. Bots open separate chats with all 5 contacts, who can share a wallet address to use for recovery
  4. Bot deploys smart contract with recovery.

If recovery needs to happen. bot can help guide through the recovery, and get the signature from guardians via chat.

1 Like
6

I’ve realised, I’ve expressed enthusiastic support for this initiative in multiple calls, DMs, and various chats, BUT I haven’t officially done so right here at the source! :smile:

So, let me fix that now: I’m fully behind the local bot architecture direction. It elegantly addresses decentralisation, user privacy, and empowers users with direct control. Excited to see this move forward and eager to collaborate on refining it further!

As I’ve said in our chats I’m currently working on building a framework to allow us to introduce the much needed extensibility into the Status app, particularly as we do not have a Dapp browser at the moment. My effort on this issue is majorly inspired by this very post and the current product needs we have.

I’m really excited about sharing more work on this issue.

1 Like