Re-using known org-expiry drawer format instead of " Captured On: [yyyy-mm-dd DDD hh:mm]"

[novoid]

Hi,

I'm testing Orgro (in parallel to Orgzly Revived) for mobile capture only.

When I captured a few test entries, I got entries that looked like:

* [[https://cosocial.ca/@timbray/115917100220206490]]
  Captured On: [2026-01-18 Sun 18:38]
* [[https://taskernet.com/shares/?user=AS35&id=Profile%3AReply+Location+To+SMS+From+Special+Contact][Tasker Share]]
  Captured On: [2026-01-18 Sun 18:38]
* [[https://github.com/amake/orgro/issues][Issues · amake/orgro · GitHub]]
  Captured On: [2026-01-18 Sun 18:39]

I really do like that Orgro is including the time-stamp of the capture process. However, I do have found prior art with respect to the format.

For many years, I'm using org-expiry-insinuate in order to get :CREATED: [yyyy-mm-dd DDD hh:mm] drawer entries in my orgdown files whenever I create a new heading, e.g., by CTRL-RET: org-expiry.el

While this is a byproduct of the package which actually manages expiration dates (which I don't use at the moment), I do think that using a property drawer entry for this meta-data is a cleaner way of storing stuff like that. Maybe in future, Orgro wants to add other meta-data like origin of a shared information (calling app), username, ... to each captured heading.

Therefore, I would like to challenge switching the capture template format so that the example above would rather look like:

* [[https://cosocial.ca/@timbray/115917100220206490]]
:PROPERTIES:
:CREATED:  [2026-01-18 Sun 18:38]
:END:

* [[https://taskernet.com/shares/?user=AS35&id=Profile%3AReply+Location+To+SMS+From+Special+Contact][Tasker Share]]
:PROPERTIES:
:CREATED:  [2026-01-18 Sun 18:38]
:END:

* [[https://github.com/amake/orgro/issues][Issues · amake/orgro · GitHub]]
:PROPERTIES:
:CREATED:  [2026-01-18 Sun 18:39]
:END:

[amake]

I'm pretty sure I took the current format from the L template suggested by the Org Capture Extension:
https://github.com/sprig/org-capture-extension?tab=readme-ov-file#set-up-handlers-in-emacs

I like the idea of a more structured metadata storage. Ideally the entire template would be customizable, but I can't think of a UI that would be reasonable on mobile. I will think about whether I want to change the defaults.

[amake]

I did think about making the template customizable, but a major difficulty is that the sharing mechanisms on iOS and Android really don't guarantee the presence of all three parameters (url, title, and body); it very much depends on what the originating app decides to offer, and this is something the user can't predict or control.

Orgro currently constructs the captured content programmatically in order to handle all possible combinations of supplied parameters. To reproduce this via an org-capture-templates-like mechanism we would need many templates. Having to specify many templates doesn't seem reasonable.