[NXT] API 2 Brainstorming - page 2. | Bitcointalksearch.org

ferment

full member

Activity: 168

Merit: 100

IDEX - LIVE Real-time DEX

Quote from: ^[GS]^ on January 10, 2014, 12:11:30 AM

I think it would need to have an API to see if an account is or not forging.

isForging(ACCOUNTID) = Boolean(True/False)

Forging is an interesting issue as I think it's technically in what I refer to as the Client supporting servlet (lock and unlock) and not the api. So, I'm not sure how forging will be handled.

I put generateBlock and a placeholder for a call to determine when an account could try to generate a block.

C-f-B?

wesleyh

sr. member

Activity: 308

Merit: 250

Api call to see number of peers that accepted a transaction. This allows us to set a good value for pushTreshold.

^[GS]^

member

Activity: 112

Merit: 10

I think it would need to have an API to see if an account is or not forging.

isForging(ACCOUNTID) = Boolean(True/False)

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: marcus03 on January 09, 2014, 04:22:05 PM

What is the advantage of moving the crypto from server to client?
On the contrary, wouldn't it be better to even have the secret input dialog in the core, so that clients don't even get access to it?

Service Providers will earn money by working as public nodes. And casual users won't need to install Java and NRS server part.

marcus03

full member

Activity: 224

Merit: 100

Quote from: Come-from-Beyond on January 09, 2014, 04:16:23 PM

Quote from: ferment on January 09, 2014, 03:45:54 PM

So, all of the APIs that currently have a secretPhrase need a variation that assumes the client does their own crypto.

It seems like a bounty project in itself to implement NXT client libraries that do the crypto in different languages.

Seems so. Anyway, Legacy API will be supported too. For the time being.

What is the advantage of moving the crypto from server to client?
On the contrary, wouldn't it be better to even have the secret input dialog in the core, so that clients don't even get access to it?

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: ferment on January 09, 2014, 03:45:54 PM

So, all of the APIs that currently have a secretPhrase need a variation that assumes the client does their own crypto.

It seems like a bounty project in itself to implement NXT client libraries that do the crypto in different languages.

Seems so. Anyway, Legacy API will be supported too. For the time being.

ferment

full member

Activity: 168

Merit: 100

IDEX - LIVE Real-time DEX

Quote from: marcus03 on January 09, 2014, 03:31:04 PM

When the client signs the transaction, there is no need to send the SECRET, right?

Quote from: Come-from-Beyond on January 09, 2014, 03:32:53 PM

Right

So, all of the APIs that currently have a secretPhrase need a variation that assumes the client does their own crypto.

It seems like a bounty project in itself to implement NXT client libraries that do the crypto in different languages.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Right

marcus03

full member

Activity: 224

Merit: 100

Quote from: Come-from-Beyond on January 09, 2014, 03:00:10 PM

Quote from: marcus03 on January 09, 2014, 02:53:46 PM

Would a public/private key encryption for the SECRET make sense? Since we'll never have valid SSL certificates?

-Client requests public key from server
-Server send public key to client
-Client enrcrypts SECRET with servers public key. SECRET -> ESECRET
-Client can send commands with parameter SECRET or ESECRET
-Server decrypts ESECRET to SECRET and does the sendMoney, etc.

Clients must sign transactions by themselves.

I was looking for a way to get the plain text secret off the communcation channel between client and server.

If you currently use sendMoney, assignAlias, getAccountId, etc. the SECRET is in plain text and my idea was to prevent this. Won't these calls be available in API v2?

When the client signs the transaction, there is no need to send the SECRET, right?

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: ferment on January 09, 2014, 03:02:56 PM

oh yeah, it can get the timestamp of each block to determine direction. smart...

Not smart, just lazy.

ferment

full member

Activity: 168

Merit: 100

IDEX - LIVE Real-time DEX

Quote from: Come-from-Beyond on January 09, 2014, 02:59:37 PM

Quote from: ferment on January 09, 2014, 01:37:25 PM

getPreviousBlocks(start, end)
getNextBlocks(start, end)

Can't it be replaced with just

getBlocks(start, end)

?

We could do something similar with:
getNextBlock(current)
getPreviousBlock(current)

getBlock(offset) - where offset is plus/minus.

Although for APIs I like the literal stuff like getNextBlock(current).

ferment

full member

Activity: 168

Merit: 100

IDEX - LIVE Real-time DEX

Quote from: Come-from-Beyond on January 09, 2014, 02:59:37 PM

Quote from: ferment on January 09, 2014, 01:37:25 PM

getPreviousBlocks(start, end)
getNextBlocks(start, end)

Can't it be replaced with just

getBlocks(start, end)

?

oh yeah, it can get the timestamp of each block to determine direction. smart...

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: marcus03 on January 09, 2014, 02:53:46 PM

Would a public/private key encryption for the SECRET make sense? Since we'll never have valid SSL certificates?

-Client requests public key from server
-Server send public key to client
-Client enrcrypts SECRET with servers public key. SECRET -> ESECRET
-Client can send commands with parameter SECRET or ESECRET
-Server decrypts ESECRET to SECRET and does the sendMoney, etc.

Clients must sign transactions by themselves.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: ferment on January 09, 2014, 01:37:25 PM

getPreviousBlocks(start, end)
getNextBlocks(start, end)

Can't it be replaced with just

getBlocks(start, end)

?

marcus03

full member

Activity: 224

Merit: 100

Would a public/private key encryption for the SECRET make sense? Since we'll never have valid SSL certificates?

-Client requests public key from server
-Server send public key to client
-Client enrcrypts SECRET with servers public key. SECRET -> ESECRET
-Client can send commands with parameter SECRET or ESECRET
-Server decrypts ESECRET to SECRET and does the sendMoney, etc.

ferment

full member

Activity: 168

Merit: 100

IDEX - LIVE Real-time DEX

Another thing that would be nice is REST urls for the api instead "nxt?requestType". This helps simplify movement to a new api while supporting the old for a while.

Examples:

GET /api/block/2680262203532249785
GET /api/block/list?start=2680262203532249785&end=3705873229391760257

GET /api/account/id?secret=SECRET
GET /api/account/balance
GET /api/account/aliases

GET /api/hallmark/encode?secret=SECRET&weight=100&date=2014-1-9&host=nxt.awesome.is

POST /api/payment/send
POST /api/alias/assign

This style would also make the list of API calls much smaller by condensing them.

ferment

full member

Activity: 168

Merit: 100

IDEX - LIVE Real-time DEX

For the high level, batch payments?

sendMultiplePayments via POST with json.

Personally I think sendMoney and anything involving creating transactions should be POST.

ferment

full member

Activity: 168

Merit: 100

IDEX - LIVE Real-time DEX

Quote from: Come-from-Beyond on January 09, 2014, 01:23:48 PM

Quote from: ferment on January 09, 2014, 01:15:33 PM

While we're at high level stuff... how about some blockchain walking calls?

getNextBlock
getPreviousBlock

How the server will know what the current block is?

Another set of cool ones would be getting a range:

getPreviousBlocks(start, end)
getNextBlocks(start, end)

ferment

full member

Activity: 168

Merit: 100

IDEX - LIVE Real-time DEX

Quote from: Come-from-Beyond on January 09, 2014, 01:23:48 PM

Quote from: ferment on January 09, 2014, 01:15:33 PM

While we're at high level stuff... how about some blockchain walking calls?

getNextBlock
getPreviousBlock

How the server will know what the current block is?

Pass it in. So you could walk with this pseudo code:

Code:


last = getLastBlock
while last
  last = getPreviousBlock(last)
end

next = getFirstBlock
while next
 next = getNextBlock(next)
end

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: ferment on January 09, 2014, 01:15:33 PM

While we're at high level stuff... how about some blockchain walking calls?

getNextBlock
getPreviousBlock

How the server will know what the current block is?

Topic: [NXT] API 2 Brainstorming - page 2. (Read 5024 times)