URI scheme - Githubissues

status-im / specs

Specifications for Status clients.

https://specs.status.im/

MIT License

14 stars 14 forks source link

URI scheme #112

Open hesterbruikman opened 4 years ago

hesterbruikman commented 4 years ago

Might be paired with an identifier spec if it makes more sense to document how they are used in the URI scheme

Structure of this spec should include:

Scheme syntax
Scheme semantics
Encoding considerations
Security considerations
Applications that use the scheme (including e.g. join.status.im, dapps, Keycard)
Operations
Context of use
Contact for change requests

For reference see https://tools.ietf.org/html/rfc7595 https://en.wikipedia.org/wiki/Magnet_URI_scheme https://handbook.scuttlebutt.nz/concepts/identity

Content should cover

Identities
Transactions (any EIP's)

hesterbruikman commented 4 years ago

@andremedeiros can you check if these spec requirements make sense? I have zero experience documenting URI schemes

andremedeiros commented 4 years ago

Look at status-im/status-go#1937 for reference.

3esmit commented 4 years ago

For Ethereum specifics, I suggest: Falling into ERC-831:

ethereum:pay-: ERC-681, opens payment wall with default account;
ethereum:tx-: ERC-2400, checks and display transaction (offer link to view in etherscan).
ethereum:app- ERC-TBD, opens a etheruem based DApp;

For Status specifics, I suggest:

status:#channel: a public channel;
status:@0x"68 bytes": a pubkey (private chat);
status:@anything.eth: resolve a pubkey (private chat);

It's important that we have everything as URIs, because this would help a lot in future interoperability with other systems that should know that something is inside Status Network.

hesterbruikman commented 4 years ago

Thanks @3esmit. I think this makes a good topic for one of the next core dev calls. Will keep an eye on the agenda. Tomorrow might be a bit soon ass there's also notifications and outcome of roadmap planning to discuss, but let's see