Actually the timestamp of the DBSig of vm 0 is the recorded time for the start of a block. So while there is no API to get that timestamp, it would be an easy thing to add.
I believe that once M3 is at full speed (65 operators) and stable, who is fed and audit will be completely automated and the network will rank nodes to know who should be in the authority set and who should be audit vs fed. But I agree, this is probably too early for such an ask as we don't have visibility on how it will work concretely yet. Just putting it here for the record and keeping it in mind.
I agree with Luap, that these can be obtainable from the blockchain.I'd like to be able to get:
i) Total number of spendable factoshis (i.e. not total number issued, as that would not remove those that have been burnt)
ii) Total number of spendable EC (same as above)
Second this! This is a basic requirement for applications built on Factom to be efficient, and is a use case proposed in the Factom Whitepaper:New API proposal: get first entry of a chain (querying by chainid)
It's a common pattern in Factom to make the 1st entry of a chain special in the sense that it contains information about how to interpret the data in the chain. Being able to retrieve that entry immediately without having to traverse the entire chain could be beneficial (you want to access the "rules" of the chain first).
Ideally you would be able to select certain chains for your application, and the node/api you are talking too will cache any and all entries in that chain. Our usual philosophy is to let a layer ontop of factomd handle this, as I could see features being requested on top of this (indexing for example).Related to the previous post, one thing I would very much like to see as part of the API is caching. This is partly addressed in the recent Development Grant proposed in Factom Inc., but I would like to emphasize how important increasing the performance of chain/entry retrieval is to building real world applications on Factom. Even though developers like myself want to build apps on Factom, we're coming up on read performance hindrances that are making it difficult to make them scalable and testable. In the interim, DBGrow has been using a in house caching solution to make things perform properly.
I would agree. I don't think it would make sense to have caching or indexing built into factomd. I think that these should be separate applications developed on top of factomd. Like the in house caching solution you have created drkatz.Ideally you would be able to select certain chains for your application, and the node/api you are talking too will cache any and all entries in that chain. Our usual philosophy is to let a layer on top of factomd handle this, as I could see features being requested on top of this (indexing for example).
Hey there! This project was started within the last month and is most definitely not production ready. The library is currently usable by others via NPM but there will be breaking changes in the near future. Our roadmap places an alpha release for the project by the end of June
Bloom filters will be useful for systems built on top of Factom that need to efficiently check for duplicates. For example, a token system that requires unique nonces to prevent replay attacks when executing a transaction. When constructing the filter, it's important to know the count the filter will need to hold so the rate of false positives can be estimated.