Problems with Switchboard

[bjartek]

Was there a FLIP for the swithcboard? I have not seen one, but then I have been very busy lately.

I have somes issues with the way this is made. This is based on what we have at .find in our Profile and some experience from developing on this chain for a while.

What if i want to have something like https://github.com/bjartek/flow-sharded-wallet that can accept FlowToken.Vault and proxy that to several other users. At the moment i cannot register this with switchboard since the type of it is not FlowToken.Vault but something else.

What about the ability for a entry to say what types it supports so that you can proxy it? Kind of like we do here https://github.com/findonflow/find/blob/main/contracts/Profile.cdc#L28

This switchboard is not compatible with TokenForwarding on dapper wallet either since the type of the receiver vault is not FlowToken.Vault but TokenForwarding.

I would really like to se better events here could we create a struct like FlowTokenAuthProvider that has a provider cap and an amount, and then the option to only withdraw that amount of funds from the provider? That way you will have both sender and receiver and we can emit a good event with both from and to, i would also love to see an aditional context parameter here to send in related tags.

[alilloig]

Hi @bjartek! Thanks for rising your concerns about this. There wasn't a FLIP for this, but a rather a design proposal, as well as a PR where this feature got discussed. (This happened before summer so you may not remember it).

I'll take a look at your examples and come back to you.

[alilloig]

I'm not following you with the FlowToken.Vault thing. The switchboard exposes the deposit(from: @FungibleToken.Vault) method from the {FungibleToken.Receiver}, being able to redirect the deposited vault to a capability pointing to &{FungibleToken.Receiver} (e.g. a @ShardedWallet.Wallet)

I'm very interested in discussing how can we improve the events emitted by this contract, I'll take a calm look at that latter!

[bjartek]

Right now if I create a wrapper around an FlowToken.Vault I cannot register that said wrapper should be called when FlowToken.Vault is sent to switchboard. The dictionary stores things on implementation type not supported type or underlying type.

So the issue is not with sending funds, it is how to register when something can receive some funds.

[alilloig]

Could you post a little gist example of what you are trying to explain? You could only add Capability<&{FungibleToken.Receiver}> to the switchboard, since the goal of this was to create a single Receiver object for receiving Royalties, that could route the funds to different types of Receiver, but maybe there was a wider way of storing those Receivers that we didn't think about

[bluesign]

I think this should be a one tool of many for 1 to N distribution, this shouldn't be a standard.

This is a utility contract in my understanding. Maybe we can communicate that more clear as not standard, but a utility contract ? Like Offers or StoreFront ( though StoreFront seems a bit debatable )

This switchboard is not compatible with TokenForwarding on dapper wallet either since the type of the receiver vault is not FlowToken.Vault but TokenForwarding.

Isn't this should replace TokenForwarding ?

[bjartek]

I forked and created a small overflow script here to show my point, I only use standard flow/dapper contracts. The ExampleToken and the TokenForwader.

clone:
https://github.com/bjartek/flow-ft

run go run main.go

As you can see the last transaction fails because when i try to deposit ExampleToken to Alice it does not work because she only has TokenForwarder for ExampleToken registered and not ExampleToken

What can be done to fix it? Allow sending in the type/types your capability accepts as input.