Extension issues vs Native Discussion

[brockelmore]

Problem

After having tried to develop an extension, the limitations around event & view data flows are painfully apparent for the developer. This increases the burden for some potentially fantastic additions to the Status ecosystem and leads to degradation of the usefulness of Extensions.

Pain points:

1. Not being able to arbitrarily call events from a view; See the kyber extension example for an example of a lot of this. i.e. I have to create a "completed" variable in the view then have an if statement and define the completed as true at the end of an event, but the event can only be called from specific actions like a button press. I cannot, for example, call the event arbitrarily and on completion show the view. I must click a button to call the event or use another component that implements an :event. This wouldn't be that bad as you can theoretically use an on-open event to call a series of events... except not every event ends with the ability of :on-success or better yet :on-finish :event, additionally see next issue.

2. wallet hooks :on-open leads to errors - I can post more on this if others cannot reproduce by creating any wallet hook with an :on-open event.

3. Comparative logic of variables; i.e. if/then blocks are too limited as there is almost no way to define anything as true or false on client side. Say I want certain behavior if the price of ethereum is under $90, then show view x, or have a color be red.

4. Confusing access to variables, including but not limited to: order of reference objects in map, passing variables into events, etc can be annoying and current debugging is limited (lack of debugging is likely the real issue here)

5. Lack of string formatting ability; i.e. splice a string (if its a float, there is no way to stop at 2 decimal places)

6. No number to string conversions

7. Random access to vectors is impossible - no way to access 0th, 2nd, 1st, etc. For loop with no comparative logic makes this impossible in even round about ways.

The real issue I guess is that extensions purpose this ideal of being data flows and not a programming language. If just interacting with Web 3.0 and smart contracts, some of these issues go away, but extensions are sold as a way to bring some Web 2.0 into the ecosystem. Web 2.0 APIs are a great way to extend the usefulness of Status and make it more well rounded. Extensions are a great way to stop-gap between the two but functionality is severely lacking.

Future Steps

I want to open a dialogue around whether there should be space for people to submit native extensions that have full clojure logic and a true programming language instead of just data flow extensions.

My proposal is this: 2 types of extensions, native & data flow. Native get submitted to a maintained repo that people can install and gives devs more tools but more oversight, and permissionless data flow extensions continue as planned.

edit: added 7

[mandrigin]

@brockelmore I agree that a full-fledged programming language is more convenient.
But how do you protect the users from malicious extensions in that case?

As I understand, one of the ideas of this design was being able to protect users from tracking, stealing data, etc.

cc @corpetty @jeluard

[jeluard]

As pointed by @mandrigin one of the pillar behind the extensions design is to prevent unexpected runtime behavior. The limited scope of extensions provides this: they can be analyzed dynamically and all details presented to the end user for approval.

Also keep in mind that extensions are alpha (advertised as such) and lack the maturity you might expect from programming environment.

but extensions are sold as a way to bring some Web 2.0 into the ecosystem.

It is certainly not the intention to advertise as such. Did you get this impression from a link on our docs website?

Some of your points are bugs and we will address them. Can you clarify some of your questions:

• How to handle multiple numbers on phone account? #1 Do you have an example f when you would need that?
• hash comparison with circleci artifacts #5 strings can be formatted e.g. "My number ${number:1.2f}"
• How is merge light-api with develop #6 different than hash comparison with circleci artifacts #5 ?
• chat dapp permissions #7 vectors can be destructured (e.g. (let [[a _ c d] [1 2 3 4]])) but not sure this is what you want

[cammellos]

Closing this, I would suggest moving the discussion to https://discuss.status.im/ (there are similar posts already).
thanks