Contract nitpick: entry id not enough to look up IPFS multihash

[karalabe]

I would have expected the entry ID to be enough to look up any data related to it. However, there are multiple things that cannot be done:

The entries are stored in a Solidity mapping(address => mapping (bytes32 => IpfsHash.Multihash)). This means that the entry ID in itself is useless without the sending account's address. This is imho not the best design, because it complicates entry lookups and (imho) doesn't really provide any benefits (I can brute force the account if I really want, so it's not aiding privacy, only acts as an annoyance). I'd suggest to have the mapping (bytes32 => IpfsHash.Multihash) as a global variable and nor per account embedded into some other struct. That would enable CALLs to access entries by ID, without requiring to derive the user first.

The second issue is that even if I have the publisher's address and entry id (enough to access the post), they are still not enough to figure out the timestamp of the post. That one can only be derived by filtering for the event ID and extracting the block number/timestamp from the log. That's imho a whole lot of extra processing to pull up a seemingly trivial piece of data. I'd venture to suggest to store either the block number of the timestamp of the entry in the Ethereum contract to make direct by-entry-id lookups more meaningful.

Note, I know both of these mean new contracts, which entails relaunching everything. Not sure how feasible that is, whether you can migrate user data or not. Just wanted to highlight these limitations that get bite you in the long term with the data accesses.

[kenshyx]

We're using the Publish event from Entries contract to lookup for a specific entry ID when the author is not available. For the second issue regarding the timestamp of a post, we're calculating it by subtracting the voting_period(Entries) from Votes contract (records[_source].endPeriod) where _source is the entry Id. We're gonna change these in the next contract updates(v0.7.0).

[karalabe]

I'm mostly trying to put a restful API on top of the Akasha contracts, and am trying to limit the number of filterings I have to do, since long term those will become expensive to scan the entire chain. So to pull all the posts of a user (maybe bound by timestamp), it's obviously necessary to filter. But to get the details of a single post (which might end up one of the most common queries), filtering the entire chain for it feels bad.

Thanks for your suggestion with the timestamp, will check it out.

[karalabe]

Another random thought. If I remember correctly, the entry id is keccak256(author, nonce, timestamp). If you omit the timestamp from the calculation, then we could locally generate the entry ID for the next post and not require for filtering when gathering the posts of a known user.