[Request] Change/Add API commands #194

New Issue

2013-06-06T12:35:56+02:00

AyrA commented

2013-06-06 12:35:56 +02:00

(Migrated from github.com)

Change API commands

generally commands should be changed, so the "addSomething" commands will actually edit existing entries.

More API Commands

Below you can find suggestions

exit

If your client runs in daemon mode on windows you currently have to kill the process which may lead to a corrupt messages.dat file. Calling the exit command would gracefully shut down the client

showGui

Causes the GUI to be loaded and shown to the user.

emptyTrash

Does the same as the command in the File menu.

updateGUI

Allows a user to update the GUI.

getSubscriptions

Returns a list of subscriptions (address, Label, enabled)

getAllInboxID

The same as getAllInboxMessages but only returns ID's, causing a more performannt API because people do not always need all their 8000 Messages at once

getMessage

Gets the message with specified Message ID

addAddressbookEntry

Adds/edits an address book entry

getAddressbookEntries

Returns a list of address book entries

deleteAddressbookEntry

Deletes an address book entry.

addBlacklist

Adds a message to the Blacklist

deleteBlacklist

Removes a Message from the blacklist

getBlacklist

Returns all Items in the blacklist

add|get|delete Whitelist

Same as Blacklist but for the Whitelist.

setListMode

sets BM to blacklist or whitelist mode

getListMode

gets the current blacklist/whitelist mode.

getNetStatus

returns a list of connected nodes (IP/Port) and the number of processed messages and public keys.

connect

Connects to specified IP and Port (only makes sense if automatic connection attempts from bitmessage can be disabled)

disconnect

Disconnects from an IP

Additional commands

Additional commands should be added if an IP based black/whitelist is ever created, supporting adding/removing/returning IP addresses or ranges.

# Change API commands generally commands should be changed, so the "addSomething" commands will actually edit existing entries. # More API Commands Below you can find suggestions ## exit If your client runs in daemon mode on windows you currently have to kill the process which may lead to a corrupt messages.dat file. Calling the exit command would gracefully shut down the client ## showGui Causes the GUI to be loaded and shown to the user. ## emptyTrash Does the same as the command in the File menu. ## updateGUI Allows a user to update the GUI. ## getSubscriptions Returns a list of subscriptions (address, Label, enabled) ## getAllInboxID The same as getAllInboxMessages but only returns ID's, causing a more performannt API because people do not always need all their 8000 Messages at once ## getMessage Gets the message with specified Message ID ## addAddressbookEntry Adds/edits an address book entry ## getAddressbookEntries Returns a list of address book entries ## deleteAddressbookEntry Deletes an address book entry. ## addBlacklist Adds a message to the Blacklist ## deleteBlacklist Removes a Message from the blacklist ## getBlacklist Returns all Items in the blacklist ## add|get|delete Whitelist Same as Blacklist but for the Whitelist. ## setListMode sets BM to blacklist or whitelist mode ## getListMode gets the current blacklist/whitelist mode. ## getNetStatus returns a list of connected nodes (IP/Port) and the number of processed messages and public keys. ## connect Connects to specified IP and Port (only makes sense if automatic connection attempts from bitmessage can be disabled) ## disconnect Disconnects from an IP # Additional commands Additional commands should be added if an IP based black/whitelist is ever created, supporting adding/removing/returning IP addresses or ranges.

Arceliar commented

2013-06-06 19:27:29 +02:00

(Migrated from github.com)

Since the topic is open anyway... I'd like to see a way to retrieve the timestamp included in the original message's PoW, not just the time received.

I realize that it's not reliable, but using that as the time sent for an email client could let it mostly untangle out-of-order threads, where getting the (at least approximate) message order right may be more important than actually having an accurate timestamp.

Since the topic is open anyway... I'd like to see a way to retrieve the timestamp included in the original message's PoW, not just the time received. I realize that it's not reliable, but using that as the time sent for an email client could let it mostly untangle out-of-order threads, where getting the (at least approximate) message order right may be more important than actually having an accurate timestamp.

AyrA commented

2013-06-06 22:47:25 +02:00

(Migrated from github.com)

If you use an E-Mail client he will actually put a timestamp in the mails header so the receiver (if also using an E-Mail client) can rearrange items properly.

Arceliar commented

2013-06-07 13:37:12 +02:00

(Migrated from github.com)

True, but I try to make things look as normal as possible for normal PyBitmessage users, so at present my scripts strip that information. The timestamp already exists in the protocol, so I'd rather use that, it's just not visible at the moment.

acejam commented

2013-06-12 19:57:09 +02:00

(Migrated from github.com)

I think getNetStatus would be very helpful. If someone can point me in the right direction of what methods to hit, I'd be interested in trying to implement this.

I'm also currently implementing my own version of getInboxMessageById. If it ends up working well enough, I'll submit a pull request.

I think getNetStatus would be very helpful. If someone can point me in the right direction of what methods to hit, I'd be interested in trying to implement this. I'm also currently implementing my own version of getInboxMessageById. If it ends up working well enough, I'll submit a pull request.

grant-olson commented

2013-08-16 18:27:03 +02:00

(Migrated from github.com)

Three of the requested calls have been implemented with different names:

getSubscriptions -> listSubscriptions

getAllInboxID -> getAllInboxMessageIDs

getMessage -> getInboxMessageByID / getSentMessageByID

Three of the requested calls have been implemented with different names: getSubscriptions -> listSubscriptions getAllInboxID -> getAllInboxMessageIDs getMessage -> getInboxMessageByID / getSentMessageByID

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2025-03-03#194