These are chat archives for ethereum/ecosystem-standards
@zelig: Yes, this is really cool :)
This information could simply be appended to another JSON object describing the offchain (p2p/network) endpoint metadata. In the case of slock.it, for example, they could be a set of identity addressed, authenticated HTTP endpoints. There, a common format may not be necessary because the service could have its own dapp and the devices offer homogenous interfaces. But even more futuristic stuff such as
across a variety of devices and interfaces will require a universal format.
So for example, if I want to offer live temperature sensor data in exchange for Ether/subcurrency payments, then the specific configuration would have to be documented somewhere. This could be, for example, a "payto:ethereum" link to an address of a contract that implements some transaction model, together with the offchain API documentation.
I hope this makes sense.
So, in the case of slock.it, it probably wouldn't be desirable to do all communication on-chain, for privacy reasons alone. Instead, when the user is in the vicinity of the lock he can communicate directly with it (e.g. with Wifi/Bluetooth/NFC) and access an API (over HTTP/pubsub/Whisper/...) to open/close the lock. This has the advantage that the user does not necessarily have to be online, only the device would have to sync with the blockchain - which is only used for functionality that requires consensus, for example exclusive control over the lock, payments and registration.
So you have
A program wanting to use the device will first fetch the service descriptor from Swarm, then, if required, look up and verify the contract on the blockchain and then interact with the API and/or the contract.
a few things.. removes bloat, transmission lowered, propagation and synchronization. also the ethereum code itself could be in index 0->10000, which would be:
<using ethereum codebase 00012> <using indexed dictionary with hash 0xeia09s9> <run program 00110534> <with program constants [jsonconstantsbytes]> <with data [databytes]>
"build a smart contract with a run-only-once clause.
the contract is formed with metadata specifying a specific once-only signature, and that contract being concluded is removed from the ability to be called again.
similarly, said contracts can be reloaded with a specific token, that token allowing a specific usage parameter as specified in the contract. said tokens are worth certain values, and that contract throws unless those specific values are checked against.
this allows for a contract to have a specific ethereum balance and to spend it running function calls to middleware platforms, without being subject to run-of-service attacks where that contract could be asked to provide for too many service calls from specific other contracts.
those other tokens would be produced in an "alternative fuel" methodology, where that fuel is purchased from another contract for ethereum, and providers of a specific key can manufacture the "alternative fuel" at whim.
this could be seen as a means of bypassing a free for all ownership of smart contracts, whereupon unless said contract was replicated with a different fuel, it wouldn't function with the same resistance to run-of-service attacks.
thus that means another method of "alternative fuel" collection or another exact clone of the original fuel contract, whereupon smart usage of hierarchal branches of associated functions could lead to instant modification of a "free call tree" across all associated functions, whereupon all other cloned branches would impose a much steeper transaction cost.
it should be possible as well to virtualize the function database. if the data exists, contracts could access a data store, function call that data store in memory, and return the result."
<using ethereum codebase 00012>
could be assumed if it was only changed at fixed intervals
<using indexed dictionary with hash 0xeia09s9>
could be assumed to be rationally already defined if the contract and subcontract that calls were defined in a confirmed block.
breaking down a circuit diagram into components:
then measure and attribute by relative "novelty":