Main > Stakeholder Proposals
Proposal: Use Custom Transaction Type for P2P Fiat/Crypto On/Off Ramps
abit:
--- Quote from: CoinHoarder on March 17, 2018, 10:53:51 pm ---
--- Quote from: abit on March 15, 2018, 07:50:11 pm ---
--- Quote from: CoinHoarder on March 15, 2018, 01:27:13 pm ---
--- Quote from: pc on March 09, 2018, 11:42:35 am ---http://docs.bitshares.org/development/namespaces/chain.html#_CPPv2N8graphene5chain16custom_operationE
--- End quote ---
Ok. Thanks to @abit too.
Almost all of the proposed API calls are unneccesary, and can use the custom transaction types.
The documentation is really bad for this stuff though. Something with the schema for the commands would go a long ways. I saw there was a command that returns the schema for the custom operations, but the command does not seem to work with bitshares-ws NPM module API.
It seems like the following commands may be useful for such an implementation:
custom_operation
custom_evaluator
custom_id_type
custom_object_type
--- End quote ---
Custom operations usually do nothing other than validating authorities. So there will be no "custom_object" in the core, nor evaluator or custom_id_type. Business logic around it would be "customized" (not in the core consensus).
--- End quote ---
Ok, so custom_operation can be used for all custom operations.
How can these custom operations be queried and filtered using the API? Or would one need to download all custom operations starting from from the genesis block, and process them client-side?
If the latter, then that is definitely not ideal. Some type of query and filter API call would be handy.
I would suggest Meteor's version of MongoDB-styled syntax since custom operations are aschematic. It is easy to learn and fairly straightforward. Two API calls would cover all use cases: find_custom_operation and find_one_custom_operation. These commands should accept MongoDB-styled queries. These API calls would be very powerful for building decentralized applications on top of Bitshares. https://docs.meteor.com/api/collections.html#Mongo-Collection-find
--- End quote ---
As I've mentioned, if we do it in the node, we can write a new plugin to parse and store info about custom operations, and/or use export data to external services e.g. the Elastic Search Objects plugin (https://github.com/bitshares/bitshares-core/pull/500), then query as needed. Except doing in the node, we can also setup external scripts to listen and parse blocks then store related data to external databases e.g. MongoDb then setup 3rd services e.g. blockchain explorer to query them. Do it in client side is also possible, since some people want to verify the data by themselves.
By the way, I still think it's better to go with the "conditional payment" feature aka on-chain escrow (https://github.com/bitshares/bsips/issues/44), since custom operations enforce nothing but merely recording data.
CoinHoarder:
--- Quote from: abit on March 15, 2018, 07:50:11 pm ---
--- Quote from: CoinHoarder on March 15, 2018, 01:27:13 pm ---
--- Quote from: pc on March 09, 2018, 11:42:35 am ---http://docs.bitshares.org/development/namespaces/chain.html#_CPPv2N8graphene5chain16custom_operationE
--- End quote ---
Ok. Thanks to @abit too.
Almost all of the proposed API calls are unneccesary, and can use the custom transaction types.
The documentation is really bad for this stuff though. Something with the schema for the commands would go a long ways. I saw there was a command that returns the schema for the custom operations, but the command does not seem to work with bitshares-ws NPM module API.
It seems like the following commands may be useful for such an implementation:
custom_operation
custom_evaluator
custom_id_type
custom_object_type
--- End quote ---
Custom operations usually do nothing other than validating authorities. So there will be no "custom_object" in the core, nor evaluator or custom_id_type. Business logic around it would be "customized" (not in the core consensus).
--- End quote ---
Ok, so custom_operation can be used for all custom operations.
How can these custom operations be queried and filtered using the API? Or would one need to download all custom operations starting from from the genesis block, and process them client-side?
If the latter, then that is definitely not ideal. Some type of query and filter API call would be handy.
I would suggest Meteor's version of MongoDB-styled syntax since custom operations are aschematic. It is easy to learn and fairly straightforward. Two API calls would cover all use cases: find_custom_operation and find_one_custom_operation. These commands should accept MongoDB-styled queries. These API calls would be very powerful for building decentralized applications on top of Bitshares. https://docs.meteor.com/api/collections.html#Mongo-Collection-find
abit:
--- Quote from: CoinHoarder on March 15, 2018, 01:27:13 pm ---
--- Quote from: pc on March 09, 2018, 11:42:35 am ---http://docs.bitshares.org/development/namespaces/chain.html#_CPPv2N8graphene5chain16custom_operationE
--- End quote ---
Ok. Thanks to @abit too.
Almost all of the proposed API calls are unneccesary, and can use the custom transaction types.
The documentation is really bad for this stuff though. Something with the schema for the commands would go a long ways. I saw there was a command that returns the schema for the custom operations, but the command does not seem to work with bitshares-ws NPM module API.
It seems like the following commands may be useful for such an implementation:
custom_operation
custom_evaluator
custom_id_type
custom_object_type
--- End quote ---
Custom operations usually do nothing other than validating authorities. So there will be no "custom_object" in the core, nor evaluator or custom_id_type. Business logic around it would be "customized" (not in the core consensus).
CoinHoarder:
--- Quote from: pc on March 09, 2018, 11:42:35 am ---http://docs.bitshares.org/development/namespaces/chain.html#_CPPv2N8graphene5chain16custom_operationE
--- End quote ---
Ok. Thanks to @abit too.
Almost all of the proposed API calls are unneccesary, and can use the custom transaction types.
The documentation is really bad for this stuff though. Something with the schema for the commands would go a long ways. I saw there was a command that returns the schema for the custom operations, but the command does not seem to work with bitshares-ws NPM module API.
It seems like the following commands may be useful for such an implementation:
custom_operation
custom_evaluator
custom_id_type
custom_object_type
pc:
http://docs.bitshares.org/development/namespaces/chain.html#_CPPv2N8graphene5chain16custom_operationE
Navigation
[0] Message Index
[#] Next page
Go to full version