Stacks-wallet-web: Suporte à definição de traço padrão para tokens fungíveis (SIP 010) (por exemplo, decimais)

@psq também mencionou uma necessidade geral de suporte SIP010 na carteira da web (por exemplo, mostrando decimais, ilustrações e símbolos corretamente), portanto, ampliarei um pouco esse problema.

https://github.com/stacksgov/sips/blob/hstove-feat/sip-10-ft/sips/sip-010/sip-010-fungible-token-standard.md

@markmhx cool!

podemos rastrear o ETA desses itens de alguma forma? por exemplo, quanto tempo um item permanece no backlog e quanto tempo leva para se mover pelo Kanban?

Boa pergunta. Vou deixar esse para @andresgalante 😄

Suportar totalmente os tokens sip-010 em uma carteira (ou no explorer) provavelmente vai além de suportar o número de decimais, puxando a arte por meio do uri e do símbolo. Em vez de depender dos endpoints da API que fornecem saldos para ft-tokens nativos, todas as informações devem ser recuperadas por meio do contrato, ou seja, o saldo via get-balance-of e as transferências feitas por meio da função transfer vez de contando com a função de clareza nativa.

Não fazer isso provavelmente causará discrepâncias, pois o token pode precisar fazer outras coisas ao fazer uma transferência (verifique se ele pode ser transferido para 1 exemplo possível).

E um token pode nem mesmo usar um ft-token nativo em sua implementação (veja flexr para um exemplo, mesmo que talvez isso pudesse ser melhorado neste caso). Mais sobre isso abaixo.

Como uma dificuldade adicional, uma coisa que ainda não está clara é como as carteiras podem, no caso geral, localizar todos os tokens SIP-010 pertencentes a um endereço. Se tal token usar um ft-token nativo, o endereço do contrato pode ser inferido pelo que é retornado do ponto de extremidade Get Account Balances (https://blockstack.github.io/stacks-blockchain-api/#operation/get_account_balance). Nesse caso, o endereço do contrato pode ser extraído de SP32AEEF6WW5Y0NMJ1S8SBSZDAY8R5J32NBZFPKKZ.micro-nthng::micro-nothing usando o valor restante de :: .
No entanto, se não estiver usando um token nativo, a carteira pode exigir a capacidade de adicionar manualmente o endereço do contrato do token (como você pode fazer na metamask) para poder interagir com o token.

E posso pensar em alguns casos em que um token SIP-010 exigiria mais de um token nativo para ser implementado, então não suponha que haja um mapeamento um para um entre um token SIP-010 e tokens nativos ...

Esperançosamente, isso ajuda ... e ficaria feliz em desenvolver qualquer um dos itens acima, se necessário.

@philipdesmedt Não posso estimar a velocidade de nossa placa no momento, mas podemos começar com a fase de design desta edição em breve e estamos trabalhando esta semana no roteiro para priorizá-la sobre outras tarefas.

@psq

Esperançosamente, isso ajuda ... e ficaria feliz em desenvolver qualquer um dos itens acima, se necessário.

Assim que tivermos os designs prontos, essa pessoa pode querer implementar você mesmo?

Assim que tivermos os designs prontos, essa pessoa pode querer implementar você mesmo?

má escolha de palavra, por "desenvolver", quis dizer explicar melhor, se necessário

Queria dizer que isso impacta um possível lançamento do xBTC pela Tokensoft.

@GinaAbrams animada para ver xBTC!

Acho que isso afeta o lançamento de cada token fungível, a menos que você lance especificamente um token denominado micro, eu acho

@GinaAbrams Há algum aspecto particular do padrão exigido pela Tokensoft para o lançamento?

confirmou que tentar transferir um token sip-010 da carteira da web não funciona. Erros com

O contrato que você especificou não tem uma função transfer .

conforme esperado, pois assume que a assinatura da função de transferência é diferente.

Além disso, a mensagem que você recebe ao definir PostConditions.allow é o mesmo que ter um array vazio de pós-condições com PostConditions.deny , o que é confuso ou enganoso.

a mensagem que você obtém ao definir PostConditions.allow é o mesmo que ter uma matriz vazia de pós-condições com PostConditions.deny, o que é confuso ou enganoso.

Isso parece um problema de UX não relacionado para corrigirmos? Em caso afirmativo, pode abrir um problema para ele?

a mensagem que você obtém ao definir PostConditions.allow é o mesmo que ter uma matriz vazia de pós-condições com PostConditions.deny, o que é confuso ou enganoso.

Isso parece um problema de UX não relacionado para corrigirmos? Em caso afirmativo, pode abrir um problema para ele?

adicionado como # 1120