[NXT] API 2 Brainstorming

[ferment]

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)

[1714050725]

1714050725

[1714050725]

1714050725

[1714050725]

1714050725

[ferment]

For the high level, batch payments?

sendMultiplePayments via POST with json.

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

[ferment]

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.

[marcus03]

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.

[Come-from-Beyond]

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

Can't it be replaced with just

getBlocks(start, end)

?

[Come-from-Beyond]

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.

[ferment]

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

[ferment]

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

[Come-from-Beyond]

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

Not smart, just lazy.

[marcus03]

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]

Right

[ferment]

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

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]

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.

[marcus03]

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]

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.

[^[GS]^]

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

isForging(ACCOUNTID) = Boolean(True/False)

[wesleyh]

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

[ferment]

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?

[ferment]

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

This would be new functionality since right now Peer.sendToAllPeers (called by broadcastTransaction) doesn't keep any responses.

[Come-from-Beyond]

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

C-f-B?

Shouldn't we leave block forging for clients? Coz it's the same as signing transactions, u have to use ur secret key.