RFC 38 – Appendable Data

I have come to appreciate that it takes longer to think about good code, than type it. Saving a few key strokes, especially in a modern IDE, seems like a false economy to me (for all but counters/temp variables, etc).

I would also say that consistency is key. If it is called public/private elsewhere, then use e full name. If it is pub/priv elsewhere, use the short name. If it is different all over the place, you never know which it is without leaning on the IDE or looking it up.

Just my opinions, Ofc! :slight_smile:

2 Likes

There is currently no push mechanism for the append operation, i.e. the owner must resort to polling (as opposed to notifications) to check if (Priv|Pub)AppendableData has been updated.

This should be handled separately, no?

Nodes connected to us could broadcast a few messages of “fire-and-forget” principle (i.e. if they fail to each the destination, we don’t care). Then we could only add polling if we didn’t receive any notification from within 5 minutes or so. Can this be done ( #cc: @AndreasF )?

Possibly.
One problem is that the public keys (both of the owners and of the appenders) don’t necessarily have anything to do with their client’s public ID, so the vault doesn’t know where to push to. Not sure where that information could/should be.