Add dialog for transfer of BitShares tokens to BitShares EOS (BEOS) gateway

[dnotestein]

Is your feature request related to a problem? Please describe.
Add dialog to simplify creating a formatted memo for sending BitShares tokens to BEOS gateway. Currently in the reference wallet, a user must construct a fairly complex and potentially errorprone memo to instruct the gateway how to credit the BTS it receives.

Describe the solution you'd like
We have an existing implementation that solves this problem completely and it's been tested/operational for months now: #2935

Describe alternatives you've considered
It has been suggested that some generic method could be designed for this to support many custodians. I'm sure this is possible, and even a good idea, but I don't think it should delay inclusion of the existing implementation that is tested and working well.

Additional context
There are screenshots in the PR.

[sschiessl-bcp]

The legacy withdraw will be removed in time, thus it would be feasible to create a generic way.

I have not checked the currently supplied PR, but following things come to mind:

1. Any legal text should not be hardcoded in the wallet. A hardcoded link would be acceptable, or even better if the gateway api provides link(s) to the 3rd party entity (like T&C, liability notice or similar)
2. The gateway account should be loaded from the api
3. The allowed or needed memo format could be hardcoded, preferrably loaded from the api. Validation could optionally be possible

Which of those is already fulfilled?

Desirable is integration into the WithdrawModal

It already has the option for custom memo, adjusting that should be straightforward. You can already add withdraw and deposit features for BEOS through your existing gateway

[dnotestein]

I think trying to integrate all gateways into a common withdrawal dailog isn't a viable solution, although it's desirable where its "easy". The way to encourage this is to provide an interface that makes it easy for a gateway to do that rather than make a custom solution.

BUT, it's not a viable solution for every use-case, and I don't think it should be required. The current "legacy" design tacitly recognized this and allowed a user to select a gateway which would then take the user to a custom page which matched the needs of the gateway. Trying to discard this as an option is a mistake, IMO.

Just as a simple case for BEOS of why these customizations are useful: we're about to modify the interface for withdrawal to allow to extra checkboxes in the withdrawal dialog to allow for indicating to the gateway that the coins should be transferred in "staked" form by the gateway (either staked net or staked cpu).

[dnotestein]

This customized page also enables the gateway more control of "when" a user can take an action. For example, you suggest having "links" to legal terms. But it's certainly plausible that a gateway will want to design their pages in such a way that a user is certain to have seen it's terms before the user is allowed to transact on the gateway.

[dnotestein]

Note by the way, this is why I think these discussions are better handled in a chat window than here. We're located in different timezones and days are going by discussing something where we could at least find out if we're going to have a meeting of the minds in an hour or less rather than days.

[dnotestein]

Unless you're actively inviting others to join in the discussion, we can come to a resolution on this much quicker in a chat.

[abitmore]

@dnotestein It's true that chat is a good tool for more efficient communication. I think you can usually find @sschiessl-bcp on Telegram. It would be not too hard to arrange a meeting.

[sschiessl-bcp]

Please kindly answer my questions 1.-3. above.

The current codebase of this repository gets streamed 1:1 on bitshares.org. Including third part legal texts immediately becomes a liability issue if hosted on bitshares.org. An external link is different in that regards (imo, but no expert). Ideally we have a disclaimer popup to highlight 3rd party external content, this was an idea discussed in other issues but not realized yet.

There are two options here: a) we create a framework such that the deployment on bitshares.org differs from what is provided as light client download or b) We get bitshares.org owner onboard, and if it is necessary, is BCLA/Blocktrades willing to sign an agreement regarding the hosted texts/withdrawal capabilities?

BUT, it's not a viable solution for every use-case, and I don't think it should be required. The current "legacy" design tacitly recognized this and allowed a user to select a gateway which would then take the user to a custom page which matched the needs of the gateway. Trying to discard this as an option is a mistake, IMO.

Several reasons got into consideration here. One of them is that (almost) none of the gateways are actively helping maintain their content in the reference UI, thus I want to shift as much to API integration as possible. Adding toggle flags that are being send to the gateway API as additional parameters is also generically possible.

I understand all those ideas are in the way of getting it done quickly like you wish.

[dnotestein]

I don't think there's legal liability from replicating another entity's legal disclaimers. The legal liability is with the entity that is making the disclaimer (BLCA in this case). Even if it's an issue of the disclaimer going out of date, it's up to the entity making the disclaimer to update such disclaimers appropriately (or avoid them if it's concerned that such shouldn't be possible).

If you want BLCA to make some kind of representation to bitshares.org about it, I'm sure it would be willing to, but I don't even see what form that would take.

I understand that you would like a generic interface and I have no problem with you supporting that for gateways that want it: your given reason of "One of them is that (almost) none of the gateways are actively helping maintain their content in the reference UI, thus I want to shift as much to API integration as possible" makes perfect sense for that method. But in the case of BLCA, it's not accurate: BLCA does want to actively update it and the way it looks over time. A generic interface gets in the way of this.

So given I don't want a generic interface and the creation of such is likely to delay what I do want, I'm opposed to this process method.

Regarding your questions, I can see you were annoyed I didn't answer them, but I thought that my answer was either implicit or it was a case where I didn't know the answer and it wasn't relevant to a non-generic design:
For 1, I think it's pretty clear it's currently not a link, and we don't use a link because we want to ensure it's read. Maybe there's some way we can have a link that "auto-renders" I suppose using some javascript text, if my arguments about the lack of liability for showing someone else's disclaimer isn't compelling.
2 is only relevant for a generic design
3 I didn't fully understand, but I think it's looking for a generic way to do formatting of a memo, which again isn't relevant to a non-generic design

[startailcoon]

The legacy withdraw will be removed in time, thus it would be feasible to create a generic way.

When we move away from this section I expect that we will still need some kind of custom section for things like this. When it comes to that we would refactor it to work with any new way we handle it.

[dls-cipher]

a) A hardcoded disclaimer in bitshares.org is not possible due to legal concerns - happy to open dialog on that with our legal team if hardcoded is your desire (see at the bottom contact email)
b) We see the need to reduce marketing/branding confusion, who is who, partnerships, relationships and such. Since BitShares EOS is not a BitShares product (i.e. approved by community consensus) and an entirely different organization altogether, this needs to be mentioned and abbreviation BEOS should be used within bitshares.org products.

What is possible is the following:

• Popup modal with a sandboxed iframe to beos.world holding that disclaimer/terms (evaluation of security risks of iframe integration pending)
• Popup modal with a link to disclaimer/terms that is hosted with/loading from beos.world, or an API that returns a json payload to be displayed

If you wanna discuss different approach, or even your current one, please send email to [email protected].

P.S. Another possibility to discuss is integration of your Tab for only the light wallet.

Please, if no issues with a) and b) we would like to hear your thoughts how to proceed with actual integration.

Much appreciated,

On behalf of Move Institute ("Zavod Premik, Murska Sobota")

Milos (DL) Preocanin

Chee®s

[dnotestein]

"Since BitShares EOS is not a BitShares product (i.e. approved by community consensus)"

So, what, the BEOS guys should vote in a proposal for 1 bts daily to get it approved as a BitShares project? If the above seems a bit sarcastic, it's just because of the obvious voting power of the BEOS voting bloc, that makes this seem like an interesting viewpoint to hold to me...

[dls-cipher]

"Since BitShares EOS is not a BitShares product (i.e. approved by community consensus)"

So, what, the BEOS guys should vote in a proposal for 1 bts daily to get it approved as a BitShares project? If the above seems a bit sarcastic, it's just because of the obvious voting power of the BEOS voting bloc, that makes this seem like an interesting viewpoint to hold to me...

Not have any desire here to discuss sarcasm or emotional take on discussion, here the main point is
integration of BEOS gateway to wallet ui, correct ?

If it's being hosted within *.bitshares.org domain, terms are clear, if outside of it, no issues as explained above.

Hope we can move on to some delivery of actual gateway now since users are complaining on BEOS wallet in Telegram groups and inability to move BEOS/BTS freely.

Chee®s

[dnotestein]

"If it's being hosted within *.bitshares.org domain, terms are clear, if outside of it, no issues as explained above."

I suppose I haven't expressed myself clearly enough. Let me try again: if you don't consider the current voting stake of BEOS an opinion about approval of the project to use the name "BitShares EOS", what would you consider approval of that name sufficient to use that name? Because right now, it feels like it's the decision of one person that's preventing the usage of this term (that's what I get from "terms are clear").

"Hope we can move on to some delivery of actual gateway now since users are complaining on BEOS wallet in Telegram groups and inability to move BEOS/BTS freely."

The BEOS gateway is already integrated to the wallet ui now and it's possible to move BEOS/BTS freely. In other words, the code has already been delivered (although probably the pull request needs an update by now, but I don't see the point in submitting further pull requests if they're just going to be ignored).

It's just not integrated with wallet ui shown on bitshares.org. This whole discussion is to just get approval to accept the already written and deployed code for this gateway (deployed on bitshareswallet.beos.world) onto the wallet ui shown on bitshares.org. Because it's not, users must currently move back and forth between wallets on the two different sites, which makes an extra annoyance for users.

[sschiessl-bcp]

RuDEX has presented an alternative how to deal with custom memo types. Is that of interest as a solution to you?
#3027