Question for BCnext:

What are the most inportant 5 things the community should do, in order to properly support nxt in the next 6 months?

I hope there is a standard for every client developer, but unfortunately, no standard. so i made this rule:

Alias: yueye
Uri: nxter:acc=5693933960808456307&img=bbyk.sinaapp.com/snake.png

And we can add more, like
nxter:acc=5693933960808456307&img=bbyk.sinaapp.com/snake.png&email=xxx@gmail.com&tel=12334555

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.  


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.


URI standard defines as you've written it.


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.


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:


or publicnode as an array of URIs.


Service providers and app developers can define their own nxtdata microformats. Some will become standards and some will be specific to an app/provider.

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.

The worst outcome would be two or more conflicting approaches, with an alias definition working in one browser extension but not another. I could no longer give my 'notsoshifty' alias out to people with any confidence that it would be useful to him. Regardless of whether one approach eventually becomes dominant, the real losers would be the alias concept itself, and its (non-)users.

So I am keen for some consensus. No need for official sanctioning, but some peer review/discussion would probably be beneficial.

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'
 - A simple nxt-specific URL that references a nxt account, such as 'acct:123456789'
 - A nxt-specific URL that bundles a number of other URLs (ideas for formats as previously discussed)

And although the network doesn't insist upon it, c-f-b's idea that an alias should always reference a URL seems sound. So rather than '123456789' it should be 'acct:123456789' (or whatever).


As a side question: one important feature for nxt is the ability to send funds to a named alias rather than a number. I can see this being implemented in two ways:

1. Purely client side. The client looks up the alias to get the account ID, and then creates a transaction with that account (not alias) as the recipient
2. Within network/API. The client creates a transaction with the alias as the recipient, and the network (i.e. forging node, and other nodes through validation) translates the alias into an account id at time of forging

The second seems to me to be cleaner and preferred. Example: a transaction might take hours to get processed, and what's important is the account that the alias corresponds to at the time it gets processed, not when it is initially shoved into the network.

However, this would require API changes. And so any URI conventions that are adopted by browser extensions/addons would need to be adopted into the API.

A while back, someone (c-f-b?) mentioned putting json entries into aliases. Has anybody looked into how this might work?

As an example, I have put this into the 'notsoshifty' alias:


Or, easier to read:


So the idea would be that if "nxt:notsoshifty" was entered into a browser, the browser extension would fetch the alias, look for the 'web' entry, and go to that URL (http://www.notsoshifty.de/). A nxt client would look for the 'nxtacct' entry if it was in reference to making a payment; an email client would look for 'smtp', etc.

Ferment: if you think this is a good idea, perhaps you could modify the 22k.io site (and browser extensions?) to check for json and act accordingly? (It should also support the existing method of course). Also anybody who might be developing nxt clients using aliases as account numbers.

This 750+ page thread isn't the best place to discuss it as all history quickly gets lost. Later this evening I'll open a thread in one of the other forums and put some information there.

This reminds me a trick when u ask for 3 wishes if someone lets u to ask one wish.

Could someone give me the account numbers of the initial 70+ stakeholders? thanks!

Question for BCnext:

What are the most inportant 5 things the community should do, in order to properly support nxt in the next 6 months?