elective-stereophonic
elective-stereophonic
Public key for fresh accounts - this is a wrong decision.  
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Stable Nxt Client: Nxt 1.12.2

Pages: 1 ... 9 10 [11] 12 13 ... 17  All

Author Topic: Public key for fresh accounts - this is a wrong decision.  (Read 30117 times)

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #200 on: August 28, 2014, 06:22:18 pm »

Have to agree that Eadeqa is talking a lot of sense, and I've no idea why the devs won't consider it. It will make things easier for both users+businesses. Plus it will limit the need for new addresses. I've yet to see a disadvantage.

Getting users to enter reference numbers and sending the money back if they use the wrong reference is just creating an annoying workaround. Shouldn't making Nxt easy for businesses and users be a priority if we want Nxt to succeed?

It is not an annoying workaround. It has worked 100 years or more before. (not sure if 100 is correct, but you get the point)

My problem isn't that it's annoying . My problem is that it's error-prone as it requires the user to remember to do something, or else you as a merchant has to deal with customer support.

I would be happy if it was just  annoying but error-proof.

Good. The solution is here.

Damn, guys. What is so hard to understand about that? It is not required to be in the core.

Tell our fellow client developers to implement it and that is it.

Reach out to them and let us get started here.

It needs to be in the core -- the client side solution isn't enough as there are many clients, and will be many more clients in future and you can't guarantee everyone will support it.

 
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

ChuckOne

  • Hero Member
  • *****
  • Karma: +293/-17
  • Offline Offline
  • Posts: 3450
  • ☕ NXT-4BTE-8Y4K-CDS2-6TB82
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #201 on: August 28, 2014, 06:22:25 pm »


Why not implement nxt:// URI scheme so any exchange or seller etc can create URIs like this:

nxt://send?account=NXT-DGML-DIN8-SSD9-SQ3DU&amount=1&message=<orderid>

This solves the usability issue and does not need any core change.
The client can prefill the form with values from URI, the user only needs to enter passphrase and hit send. It doesn't get easier than clicking a link and entering a passphrase to perform a transaction.
If it can be implemented for windows, linux and mac users will be happy.

This is the same as Eadeqa suggests. The syntax does not matter at this point. Client developers and merchants should get together and confer about the most appropriate form.
Logged

ChuckOne

  • Hero Member
  • *****
  • Karma: +293/-17
  • Offline Offline
  • Posts: 3450
  • ☕ NXT-4BTE-8Y4K-CDS2-6TB82
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #202 on: August 28, 2014, 06:23:38 pm »

It needs to be in the core -- the client side solution isn't enough as there are many clients, and will be many more clients in future and you can't guarantee everyone will support it.

Rest assured if it is useful it will find its way into the core.

However, something like this needs to develop itself over time. Btw. I do not see at which place we would need it in the core. What should the core do with it?
« Last Edit: August 28, 2014, 06:26:14 pm by ChuckOne »
Logged

websioux

  • Sr. Member
  • ****
  • Karma: +69/-1
  • Offline Offline
  • Posts: 343
  • Great changes grow bottom up
    • View Profile
    • Scriba.io the Blockchain Scribe
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #203 on: August 28, 2014, 06:26:19 pm »

Tell our fellow client developers to implement it and that is it.

What if my customer use another client ?

It is not an annoying workaround. It has worked 100 years or more before. (not sure if 100 is correct, but you get the point)

The point I get is that you should get some sleep because this is quite a stupid argument ! Youpi ! lets go to paper work !
Annoying workaround are always there ! One of the task of business to get a chance to survive is to do whatever possible to minimise them.
Logged
Secret Miner <= communicate with style | NotBot <= timestamp digital docs

Sebastien256

  • Hero Member
  • *****
  • Karma: +169/-24
  • Offline Offline
  • Posts: 2823
  • ^LOOK UP^ = Nxt community!
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #204 on: August 28, 2014, 06:28:36 pm »

@chuckone,

thank for letting us know that it should beimplement in the client. Well, from a software enginerring if it can be implmenet in the client, then it is important not to put parasite into the core.

I'm happy to know that dev think long term.
« Last Edit: August 28, 2014, 06:30:44 pm by Sebastien256 »
Logged
Please drop your ideas concerning Nxt and/or NRS in this topic -> List of feature request for Nxt and/or NRS (with the full list in OP).

ChuckOne

  • Hero Member
  • *****
  • Karma: +293/-17
  • Offline Offline
  • Posts: 3450
  • ☕ NXT-4BTE-8Y4K-CDS2-6TB82
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #205 on: August 28, 2014, 06:37:10 pm »

Tell our fellow client developers to implement it and that is it.

What if my customer use another client ?

What if Internet Explorer does not support my Website? I better make sure it does.
Logged

ChuckOne

  • Hero Member
  • *****
  • Karma: +293/-17
  • Offline Offline
  • Posts: 3450
  • ☕ NXT-4BTE-8Y4K-CDS2-6TB82
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #206 on: August 28, 2014, 06:39:38 pm »

@chuckone,

thank for letting us know that it should beimplement in the client. Well, from a software enginerring if it can be implmenet in the client, then it is important not to put parasite into the core.

I'm happy to know that dev think long term.

You are welcome.

@all

Client developers and merchants should come together and discuss what the most appropriate form for them would be for a compressed payment description would be.

We have two proposals: 1) NXT-AB-CD-EF-GH/very_important_number 2) nxt:// scheme
Logged

websioux

  • Sr. Member
  • ****
  • Karma: +69/-1
  • Offline Offline
  • Posts: 343
  • Great changes grow bottom up
    • View Profile
    • Scriba.io the Blockchain Scribe
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #207 on: August 28, 2014, 06:42:35 pm »

Client developers and merchants should get together and confer about the most appropriate form.

That may be right, but this yields to an uncomfortable situation where different clients might behave differently. When it's in the core, merchant are garanteed that it always work.

I still hope we will have some arguments on why this could not be planned for the core ?

Logged
Secret Miner <= communicate with style | NotBot <= timestamp digital docs

Sebastien256

  • Hero Member
  • *****
  • Karma: +169/-24
  • Offline Offline
  • Posts: 2823
  • ^LOOK UP^ = Nxt community!
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #208 on: August 28, 2014, 06:46:04 pm »

Client developers and merchants should get together and confer about the most appropriate form.

That may be right, but this yields to an uncomfortable situation where different clients might behave differently. When it's in the core, merchant are garanteed that it always work.

I still hope we will have some arguments on why this could not be planned for the core ?

Core dev may put on some webpage what should be the standard use case for the client develloper. I think it is the core dev to setup what the standart should be. A discussion involving three party, merchant, client dev and core dev. People need to etablish standart.
« Last Edit: August 28, 2014, 06:49:11 pm by Sebastien256 »
Logged
Please drop your ideas concerning Nxt and/or NRS in this topic -> List of feature request for Nxt and/or NRS (with the full list in OP).

websioux

  • Sr. Member
  • ****
  • Karma: +69/-1
  • Offline Offline
  • Posts: 343
  • Great changes grow bottom up
    • View Profile
    • Scriba.io the Blockchain Scribe
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #209 on: August 28, 2014, 06:49:34 pm »

What if Internet Explorer does not support my Website? I better make sure it does.

And your website can not use fancy functionalities that only super NRS Firefox has implemented.

 
Logged
Secret Miner <= communicate with style | NotBot <= timestamp digital docs

websioux

  • Sr. Member
  • ****
  • Karma: +69/-1
  • Offline Offline
  • Posts: 343
  • Great changes grow bottom up
    • View Profile
    • Scriba.io the Blockchain Scribe
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #210 on: August 28, 2014, 06:50:48 pm »

People need to etablish standart.

The standart is the protocol, this is the core
Logged
Secret Miner <= communicate with style | NotBot <= timestamp digital docs

ChuckOne

  • Hero Member
  • *****
  • Karma: +293/-17
  • Offline Offline
  • Posts: 3450
  • ☕ NXT-4BTE-8Y4K-CDS2-6TB82
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #211 on: August 28, 2014, 06:51:51 pm »

Client developers and merchants should get together and confer about the most appropriate form.

That may be right, but this yields to an uncomfortable situation where different clients might behave differently. When it's in the core, merchant are garanteed that it always work.

After some time, things will sort out themselves. Who knows? Maybe, everybody likes Eadeqa's suggestion, implement it right away in their clients and spread the word.

I still hope we will have some arguments on why this could not be planned for the core ?

Successful projects pick the fully-fledged and bullet-proof ideas and method and integrate them to enhance their status from a de-facto standard to a real standard.

In this case, Nxt Core will pick the winner when it is widely adopted and accepted by most users. It is not necessary here for the Core devs to pre-maturely define what should be standard and what not. (look at the public key announcement)
Logged

ChuckOne

  • Hero Member
  • *****
  • Karma: +293/-17
  • Offline Offline
  • Posts: 3450
  • ☕ NXT-4BTE-8Y4K-CDS2-6TB82
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #212 on: August 28, 2014, 06:54:06 pm »

People need to etablish standart.

The standart is the protocol, this is the core

That is what the difference between workaround and a solution is.

The Nxt Protocol is the Core. It provides procedures for MACHINES to communicate with each other in a standardized way.

It is NOT made for humans. That is part of the client.
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #213 on: August 28, 2014, 07:12:24 pm »

It's pretty clear now that Nxt in it current form can't be used by merchants. It's fundamentally broken.

coinomat: Here is a suggestion that will definitely work: don't use Nxt as a merchant. Will save you a lot of trouble than dealing with these problems
« Last Edit: August 28, 2014, 07:14:40 pm by Eadeqa »
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

ChuckOne

  • Hero Member
  • *****
  • Karma: +293/-17
  • Offline Offline
  • Posts: 3450
  • ☕ NXT-4BTE-8Y4K-CDS2-6TB82
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #214 on: August 28, 2014, 07:14:50 pm »

It's pretty clear now that Nxt in it current form can't be used by merchants. It's fundamentally broken.

coinomat: Here is a suggestion that will definitely work: don't use Nxt as a merchant. Will solve you a lot of trouble than dealing with these problems

Let us not give up that easily.
Logged

Squeaker

  • Jr. Member
  • **
  • Karma: +1/-0
  • Offline Offline
  • Posts: 30
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #215 on: August 28, 2014, 07:36:52 pm »

It seems that some are making it more difficult than it needs to be...

Take network addressing for example... (IPv4 in this one)

Say my computer is at 127.1.45.90... we're already accustomed to routing packets to 127.1.45.90:80 or 127.1.45.90:6333 or whatever other service is on whatever port... It is absolutely nothing to us to include the port with the IP address as just a part of the whole destination address. When we leave it off? The destination port is chosen by default, depending on what we're doing, as far as we can see, but everything is routed to a port.

Now, say my wallet is at NXT-S48J-AVQZ-WBER-5B7HB... so the coin will be routed to me at that address, but what is the coin is for? Use a reference number, same function as a port number would be... if you don't have a reference number, your coin gets routed to the default reference # (zero)

A vendor who has specified their address on the blockchain as requiring a reference/destination number, will need all funds sent to them to include a reference number. Anything except a 0 (zero).

The coin itself wouldn't be held separate from the rest of the coin at that address, effectively, all piece of coin would be at reference/destination zero... the blockchain itself wouldn't have to keep those separate... but when the client reports the received transactions, it will list the reference/destination code included in the transaction... and that destination address, can be saved in the client as NXT-S48J-AVQZ-WBER-5B7HB:4227 ... that 4227 could be the order number, or it could be my customer number. It may be better off for it to be customer number for some vendors, and order number for other vendors, depending on how they interact with their customers... but that doesn't matter to the client.

"NXT-S48J-AVQZ-WBER-5B7HB:4227" would be the full destination address you put into the destination field of your transaction. The client would parse it out itself... and you could save that fully-qualified destination address in your contact list, so the :4227 would always be attached in your contact list, if you wish.

To me, this would be the simplest way for the end user, and there shouldn't be any reason why you couldn't include it in a QR code. It doesn't even have to be the colon, could be an equals, or a tilde, something that parses well in URLs...

It would need to be included in the transaction in the blockchain, but functionally, it would be ignored as far as where the coin is credited to, since only the end-user would make use of the reference/destination #.

We do seem to have a habit of overthinking things, sometimes, when the KISS method works best for the user's usability.

We shouldn't have to make the end user do extra things that can be handled in a streamlined fashion with code, under the hood.

This just seems to be a bigger debate/fight, than it needs to be.

=squeak=
« Last Edit: August 28, 2014, 07:39:30 pm by Squeaker »
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #216 on: August 28, 2014, 07:43:13 pm »


We shouldn't have to make the end user do extra things that can be handled in a streamlined fashion with code, under the hood.
This just seems to be a bigger debate/fight, than it needs to be.

Exactly. This isn't a difficult change for the core. It's pretty simple parsing the reference ID (which is same as "message") from account ID.
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

Squeaker

  • Jr. Member
  • **
  • Karma: +1/-0
  • Offline Offline
  • Posts: 30
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #217 on: August 28, 2014, 07:52:40 pm »


We shouldn't have to make the end user do extra things that can be handled in a streamlined fashion with code, under the hood.
This just seems to be a bigger debate/fight, than it needs to be.

Exactly. This isn't a difficult change for the core. It's pretty simple parsing the reference ID (which is same as "message") from account ID.
I was thinking more about 'reference' being separate from 'message'... with 'reference' serving a very specific purpose, and 'message' being more general, and could be anything.

That's just how I'd do it... :shrugs:

=squeak=
Logged

Eadeqa

  • Hero Member
  • *****
  • Karma: +83/-68
  • Offline Offline
  • Posts: 1888
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #218 on: August 28, 2014, 07:58:05 pm »


Quote
was thinking more about 'reference' being separate from 'message'... with 'reference' serving a very specific purpose, and 'message' being more general, and could be anything.

That's just how I'd do it... :shrugs:


That will make it more difficult to implement. We already have a message field (which by the way can also be encrypted if the merchant wants reference field to be secret).  Just  parse the message from account ID. How difficult could that be? It should be pretty simple implementation for the core.
Logged
NXT-GZYP-FMRT-FQ9K-3YQGS

coinomat

  • Hero Member
  • *****
  • Karma: +214/-18
  • Offline Offline
  • Posts: 1520
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #219 on: August 28, 2014, 08:02:01 pm »

Well I still like NXT and see a lot of potential. But this is very disconcerting of course.
This and recent BTER situation. NXT devs are definitely doing something which can eventually lead to NXT demise.

JUST CHANGE THE WIKI PAGE AT LEAST.

It's pretty clear now that Nxt in it current form can't be used by merchants. It's fundamentally broken.

coinomat: Here is a suggestion that will definitely work: don't use Nxt as a merchant. Will save you a lot of trouble than dealing with these problems
Logged
Time to go further
Pages: 1 ... 9 10 [11] 12 13 ... 17  All
 

elective-stereophonic
elective-stereophonic
assembly
assembly