Skip to content

Conversation

@romeo4934
Copy link
Contributor

No description provided.

@romeo4934 romeo4934 mentioned this pull request Nov 12, 2020
@ligi
Copy link
Member

ligi commented Nov 12, 2020

just wondering if a wildcard like this could make sense "eip155:*"
as far as I understand with this change this would not be possible

@romeo4934
Copy link
Contributor Author

Yes Pedro mention this usecase in the issue. However, I was just thinking that it could be a little bit confusing because it means the character "*" could break regex rules for CAIP:2

@romeo4934
Copy link
Contributor Author

romeo4934 commented Nov 12, 2020

I can add it if needed?

@ligi
Copy link
Member

ligi commented Nov 12, 2020

I think the * must not match the CAIP:2 rules. It is not part of CAIP-2 in this case. Just think "accepting all eth chains" could be a nice use case. But no strong opinion on this. Waiting for @pedrouid 's input.

@pedrouid
Copy link
Member

I'm still all debating this personally because on one hand the wildcard will introduce complexity to the CAIP-2 specification but on the other I don't see many better alternatives.

I would love to actually schedule a call to work on something that I think would be extremely beneficial for many blockchain projects. A working group for building a specification for a CAIP provider that could include both CAIP-24, CAIP-25 and other potential proposals to develop something analogous to EIP-1193 spec

@ligi
Copy link
Member

ligi commented Nov 12, 2020

I am not sure the wildcard should be part of CAIP-2. Maybe part of this CAIP or an CAIP that extends CAIP-2 with wildcard options (then blochain IDs instead of blockchain ID)

LMK when the call will be - ideally for me wednesday would work

@romeo4934
Copy link
Contributor Author

romeo4934 commented Dec 11, 2020

I am happy to do a call as well! For starname, we need to be able to query wallets and know which chains they support so we can ask and get all their accounts. So we can add a wildcard or we could add another type of query to get the list of chains a wallet support.

@romeo4934
Copy link
Contributor Author

romeo4934 commented Jan 5, 2021

Should we abandon this idea and create another method to get the list of chainIds that a wallet provider support? @pedrouid @ligi

@pedrouid
Copy link
Member

pedrouid commented Jan 7, 2021

Actually I think that's a better idea which is already in line with #24

@romeo4934 romeo4934 closed this Jan 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants