Quote from: ferment on January 01, 2014, 01:54:54 PM

Quote from: wesleyh on January 01, 2014, 01:09:35 PM

1. I've decided to join forces with ferment (owner of 22k.io), as it's import to cooperate on one of the best features of Nxt and not confuse users with multiple extensions and what not.

Alright! I think we can go really fast this way. The clock is ticking!

Quote

2. Now, there is a bit of a difference between my extensions and what 22k.io currently has. I would like some community input on which approach is best.

- 22k.io extensions are "thin clients".

- My extensions are "thick clients".

Which approach is technically best? I don't know. Perhaps a combination of the two could also be done; if the alias is a simple URI or email address, the client handles it, otherwise it's sent to 22k.io which can then show account info, etc...

I think a hybrid model would be good. Like an option where one could choose "public nxt nodes" or "22k.io" as the source of info. So there will naturally be a trade off on trust vs features.

Thick clients (extensions, native apps, mobile apps with code) are more of a long term investment for the community as they require significant overhead of multiple codebases, releases, distribution, etc.

Thin clients will allow us to test the functionality and progress rapidly.

Both are necessary.

Quote

3. We also have to be careful about security. Especially when it comes to aliases that refer to an account.

If a node is compromised, it could return the attacker's ID instead of the real account ID. This could result in stolen coins if you send to that ID.

That's why it's perhaps better to connect to multiple nodes (3 or more, from different geographical ares) and ask all of them for the alias info, and only if all of them return the same information show the user the result. We also have to make sure that 22k.io is not compromised.

A valid point that supports the hybrid thin/thick model. Sensitive information should be handled in the thick client (or javascript in browser). One idea is the thick client could handle "verification" of 22k.io by providing a function to check localhost and public nodes (but not nxtbase nodes!).

Quote

4. I think it's best if this entire project would be handled as a community effort, with some kind of official sanctioning so that users know they can trust the extension/website.

I'll respectfully disagree on this point. NXT market adoption doesn't have time to wait this. My strategy is to build cool stuff and address trust issues as they arise. Sanctioning is implicit in adoption.

Quote

All code, both client side (browser extensions), as well as server side, should also be available for peer review, open-source and hosted on github. I haven't yet got word back from ferment on this.

I'm all for client stuff being open source. However, I would prefer to keep the "special sauce" closed and then open source libraries based on the work. I'm still trying to figure out how to make the NXTs off this work. If the community wants to invest, then open sourcing everything is certainly an option I'd consider. I have a 5 person dev/ops team at my disposal, but I can't pull them off paying gigs without revenue generation.

If we follow a model where security related things are always handled on the client side, then this shouldn't be an issue. If we follow a "trust, but verify" approach, the need for open sourcing as test of trustworthiness is not required (besides, I could run different code and not tell anyone).

Quote

5. We also need some kind of agreement on the json syntax and other new features.

My strategy is to just start defining stuff and implementing. If someone doesn't like the format, they're free to implement it differently. History has shown that adoption is the best form of "agreement". Let the market decide.

So, would I propose, is that we start publishing an API and spec for 22k.io as we implement support for advanced alias features and other things.

Exciting stuff!

I agree with ferment's bold statement. We need individual initiatives and responsibility. Decentralization just means everyone can take an initiative without a central party's confirmation even it is a collective party. Just do what you think is best and the market will sort out who can be trusted.