Topic: NXT :: descendant of Bitcoin - Updated Information - page 1970. (Read 2761645 times)

Utopian, thanks. COMPLETELY random like (not exactly) *&D(_xa,I7:{"X  plus another 28 characters, etc. 35 total. wth?
Gotta try to sleep now. argh!

Could you pls elaborate more on "decentralised programmable economy"  this is a powerful marketing concept.

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


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.


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!).


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.


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).


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!

How could we implement email confirmation for sending of NXT?

Update regarding Nxt Alias Browser Extensions:

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.

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". The alias entered is immediately sent to 22k.io which then processes the alias; (does a redirect, shows account info, etc.. depending on the alias). This is an advantage because new features can be added easily.

- My extensions are "thick clients". The extension itself processes the alias. It first tries to ask your localhost for the alias URI, if you have the Nxt client running on your computer. If not, it connects to a Nxt node on the internet and asks it for the alias info.

The extension then decides what to do; redirect, open an email, etc..

New features require an update to the extension. I haven't checked yet if auto-update is an option in all browsers.

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...

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.

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.

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.

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

Is this a really random pass or a passphrase that you can remember ? While Nxt security is not yeat at a desirable level I think it is an user's issue that your acc got hacked.

just wanted to add. this is found for the recipient's address in google cached view of the NXT blockchain.
16204974692852323982

not that it will help me get my NXT back I'm sure..
real lame, how my PW was cracked is beyond me.. really.

http://webcache.googleusercontent.com/search?q=cache:xOs0TPi1UPcJ:87.230.14.1/nxt/nxt.cgi%3Faction%3D3000%26acc%3D3727742886551973110+&cd=2&hl=en&ct=clnk&gl=us

Could you get a e-mail if funds where moved out of the account or if it was opened?

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.

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...

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.

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.

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.

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

Sorry to hear pal i hate thiefs with a passion. Scum of the earth they are. Do you use windows have you had remote view open at any point. Seems really strange for them to brute force a pass of 35 random characters. Did you use spaces and symbols or just dictionary words for tour password. ?

From user's perspective, I like browser's extension approach better. I still use 24k.io if I wan to check if an alias available or the total number of aliases one account has. But if I want to go directly to one alias's destination, I prefer the ease of just typing in my browser.

I use a pretty tight antivirus software ESET, all my NXT has been done local. no email or node servers.  I would love to see who this receiver is, but blockchain is down. Hopefully someone can help! thanks.

**edit
no intrusions, no viruses, weird behavior, no odd ports open etc.


It's at 51 confirmations.! is there anyway to stop this theft!??? I literally saw my client a few moments after it happened (it was open) so how this happened is odd!

My actual User account that has been stolen from is
NXT
16821029889165561706

3. Tagging aliases with semantics by using substrings. So say you wanted 22k.io to send you an email when your nxt account received funds, create an alias in your account starting with the "22knotify" in it like "22knotify2014yeehaw" with a "mailto" URI. (NOT IMPLEMENTED - yet!)

All of these would require a new URI scheme for each format so a parser could handle it.

Fun!

Update regarding Nxt Alias Browser Extensions:

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.

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". The alias entered is immediately sent to 22k.io which then processes the alias; (does a redirect, shows account info, etc.. depending on the alias). This is an advantage because new features can be added easily.

- My extensions are "thick clients". The extension itself processes the alias. It first tries to ask your localhost for the alias URI, if you have the Nxt client running on your computer. If not, it connects to a Nxt node on the internet and asks it for the alias info.

The extension then decides what to do; redirect, open an email, etc..

New features require an update to the extension. I haven't checked yet if auto-update is an option in all browsers.

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...

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.

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.

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.

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

Hash

has anyone got any thoughts of implementation on decentralized storage with NXT involvement?

if so can you discuss/inform us a bit? is it theorhetically possible?

im a programmer and im gonna do a dissertation project in the next three months and i may combine stuff to build something for next

Well, did you scan your PC with antivirus? Where do you have your node hosted? Is this shared nore or your own? Who else have access to your email / node server? Did you check node server log files? Did you see some stange behavior or errors near to this?