Hi,
while reading the topic “Counter that increments with a button click?” a question raised in my mind:
Is it possible to change values of objects or frontmatter via LUA, anyway?
Lets say I have a file with a frontmatter like
---
counter: 25
---
Of course I know, I’m able to GET the counter value via some LUA calls. But is it possible to change / set it, too?
If not, a kind of API would be nice. Of course that will have to change the values in the files, too (not only in the DB).
That’s something I will immediately try to abuse to implement the missing lastAccessed time. 
although I still think it should be implemented in the core better.
I would also love to have things like accessCount, modificationCount etc., counters in general, to get some useful statistics about pages. I do not really think that placing these and similar things in frontmatter would be correct but these things are missing now and I would be glad for any way to have them to gain some useful views based on calculated ranks, especially on notes.
Can’t things like the counter be better implemented in the JSON storage (the “mystical” .silverbullet.db.json file)? I am not sure what is this file for, it stored some JWT tocken in my case… 
Also, once at it, your idea should be extended to data manipulation in general, such as for modifying things inside the #data blocks. It also comes to mind to extend the LIQ with update (insert and delete would be far too problematic, I guess, but to allow updating already existing data will solve this too). @zef ?
Isn’t it implemented in the core?
I guess we can add all kinds of properties, but something like modificationCount could probably be implemented using git. Or then SpaceLua.
The file is not really mystical, the only use afaik is to preserve the JWT as you have seen. That’s just the only thing the server still has to store.
If done this could probably be part of the library. There are multiple ways to do this, but I guess the most robust would be to just get the markdown tree, modify, turn into text, write back. All these things are already existing functions.
Isn’t it implemented in the core?
Interesting. How do I access it? I do not see it in ${query[[from index.tag 'page']]}.
UPDATE: Missed it at the first glance, but the lastOpened is a number, not a string I would expect for timestamp…
There are multiple ways to do this, but I guess the most robust would be to just get the markdown tree, modify, turn into text, write back.
This approach starts to seem more and more natural to me…
It’s a unix timestamp in milliseconds, but it’s only stored for one “session” and only on the client, so it’s not persistent as it seems.
OK, I tend to think now that the only proper way would be via manipulating the page AST and writing the page back (or something alike), as you suggest…
How exactly is it now? What if I completely remove the browsers data? What if the timestamps on FS objects were changed (e.g. changed FS or copied or whatever?) I want all timestamps to persist and even have manual way to change them, e.g., the created value (sic!), and that needs to save them in the only data that is in fact preserved ad infinitum - the page data (the page “content”) and/or the page metadata (and/or the embedded #data data).
So, as I see it now, we need some nice Space Lua API to work with. The already existing things like created and lastModified will have to become part of the page metadata (which is, in fact, the frontmatter object) then and some hooks to manipulate them will have to be included in the standard library, of course. Things like the lastAccessed I want could then be added as custom hooks and the corresponding object stored in the frontmatter, for example. Or you can create some page with #data object full of, say, miscellaneous counters for miscellaneous things and spread buttons to increase either of them across your whole space, if you like to.
I hope I cleared the idea. Does it make some sense to you, @MrMugame?
Until now, SB has more or consistently taken the perspective that “the truth is in the markdown” that is: no (important) additional data is kept anywhere else than in encoded in markdown pages. That means you can wipe any database or cache file, and rebuild everything from markdown sources.
Adding things like accessed times and other similar things would break this assumption. Where would this data be kept persistently?
Yeah, exactly! Therefor I propose to elaborate on some Lua API to manipulate frontmatter and data blocks within page contents and to move things like timestamp created and lastModified to frontmatter and providing default hooks for them in the standard library.
But it is breaking change that will need some transition workarround for some time, or, because v2 is so new, just breaking change users will need to cope with themself.
Btw, it’s very common to have creation timestamps as a part of frontmatter in many static site generators.
Yes, creation dates make sense, however things like last accessed times etc. can’t really be done this way.
Why, please? I understand that be there a hook for it it will override local edits. But that’s intended limitation but still, it’s just a variable value and nothing else…
Some unimportant data, such as pageDecoration, used to be rules-based configurable. Sounds like the frontmatter should be layered between dynamically-generated and actually-in-the-markdown sources.