Folks - just wondering if there is any update in the alias syntax that you guys are adopting for the various browser extensions/add-ons, nxt clients, etc.
I've been head deep in rewriting 22k.io with both some semblance of design and support for searching the entire blockchain. The part involving indexing the blockchain has been a big ass rabbit hole in testing various json supporting databases.
But alas, I'm actually taking a break because my update code actually works. A nice bc cache/index is key to scaling a service provider. Then there's those 101 nodes that need updating with the new NRS.
The worst outcome would be two or more conflicting approaches, with an alias definition working in one browser extension but not another.
Standard URIs like http, https, mailto and gopher are pretty straight forward. However, whatever (extension, sites, mobile apps) interprets that URI can choose to handle however it wants. This is already the case for "mailto". On my machine with Safari, clicking a "mailto" link composes an email in Mail.app vs Chrome opening Gmail. The important thing is that format of the URI is standard.
For instance, as an alias user I would like to be able to define an alias as any of:
- A simple standard URL, such as '
http://example.com'
URI standard defines as you've written it.
- A simple nxt-specific URL that references a nxt account, such as 'acct:123456789'
The URI spec for
acct requires a @host like "nxt" or "bitcointalk" or "twitter". So, my vote is 'acct:NUMBER@nxt' and that's how I'm parsing it in 22k.io. If everyone takes up pitchforks and Wesley (and other devs) hate it, then I'm sure I can be convinced. It would be trivial to support both.
What an alias parser does with an account alias is entirely up to it: like sending money, send a message, redirect to 87.230.14.1, redirect to 22k.io, etc.
A nxt-specific URL that bundles a number of other URLs (ideas for formats as previously discussed)
I think this would be driven by the use case for that alias. Whoever implements a feature using a complex URI should take the first stab at this.
One thing worth getting consensus on is a new scheme to represent aliases that contain data structures. I propose
nxtdata with the contents being JSON. The JSON is either an array of URIs or an Object. Format of a JSON object is up to implementers. I'm not sure if existing schemes would work.
So for example, the URI for
nrsbetaversion is "0.4.9e 4e12df42f9f4727fa34eb62483880c0b2b93f45dfff4b4db8fdc293aecb815e9" (which isn't technically a URI). It could be represented as:
nxtdata:{"version": "0.4.9e", "sha256": "4e12df42f9f4727fa34eb62483880c0b2b93f45dfff4b4db8fdc293aecb815e9"}
or
publicnode as an array of URIs.
nxtdata:["http://node1.nxtbase.com", "http://node11.nxtbase.com", "http://node21.nxtbase.com"]
Service providers and app developers can define their own nxtdata microformats. Some will become standards and some will be specific to an app/provider.
