public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Smith <defendthedisabled@gmail.com>
To: Simon Richter <Simon.Richter@hogyros.de>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	tytso@mit.edu,  dsterba@suse.com, david@fromorbit.com,
	brauner@kernel.org,  osandov@osandov.com
Subject: Re: [RFC] Proposal: provenance_time (ptime) — a settable timestamp for cross-filesystem migration
Date: Wed, 25 Mar 2026 21:29:27 -0500	[thread overview]
Message-ID: <CAOx6djOJGstn-GHX_wgqOVQ6FKn7O=X-ARSi5=711JwXoQRZXA@mail.gmail.com> (raw)
In-Reply-To: <befb1cd7-f709-4e46-b08f-9c2579b10fd6@hogyros.de>

Setting an xattr user.provenance_time was a solution my AI agents
and I arrived at for meeting my immediate Windows to Linux
migration needs. The idea to submit this ptime proposal was to
help the Linux kernel maintainers better understand the types of
problems that users like me encounter when switching to Linux.

Users like me are working with AI to solve previously neglected,
and untenable problems. I believe I am amongst the first of a wave of
disruptive projects that is going to hit many industries quite hard.

Users like me are unprecedented and working on unprecedented projects.
I think of my proposal being a bit of a heads-up to the Linux maintainers.
To help you plan for what's coming by understanding the vanguard of users
that are now arriving.

My intent with the proposal was to highlight:

1. The friction I encountered in Windows made the switch to Linux
*necessary*.

2. The friction in migrating to Linux can be reduced with simple,
long-overdue changes.

3. While ptime might not be effective proof of a files provenance in terms
of forensic computing, it is metadata that is critical to effective human
and agentic workflows.

Additionally, a sworn affidavit of authenticity is one way to assert the
date created is accurate file provenance. If the system administrator
knows the integrity of the metadata is sound, then they can attest
to that under oath. But if that metadata is destroyed, there is
nothing to attest to. The date created metadata can also be corroborated
by third parties. A plan beneficiary who records a phone call with
their insurer, and the insurer representative enters call notes into
a database. It's an event that 'happened'. With enough third-party data points
verifying a private dataset, the metadata becomes something a reasonable
person should believe to be accurate.

My point isn't to argue rules of evidence or debate how AI deep fakes
will require courts to exercise enhanced scrutiny. It's to illustrate
that the date created metadata has substantive value to legal work.
Additionally, that legal work is going to become an increasingly agentic
and pro se process that can supply substantive value to society by
enabling the under-served to access justice through an open-source
stack.

My proposal for provenance_time is more about reducing friction in migrating
to Linux and optimizing real-world workflows for humans and agents.

I concede that using xattr to add ptime will be effective, but it does
introduce operational inefficiencies and overhead. Overhead that I think
it worthwhile to be mindful of. Having every users AI agents coding up
an xattr fix for an obvious problem is a lot of wasted tokens and
human attention.

Sincerely,
Sean Smith
DefendTheDisabled.org

      reply	other threads:[~2026-03-26  2:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-25  4:26 [RFC] Proposal: provenance_time (ptime) — a settable timestamp for cross-filesystem migration Sean Smith
2026-03-25  9:58 ` Andreas Dilger
2026-03-25 10:47 ` Simon Richter
2026-03-26  2:29   ` Sean Smith [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOx6djOJGstn-GHX_wgqOVQ6FKn7O=X-ARSi5=711JwXoQRZXA@mail.gmail.com' \
    --to=defendthedisabled@gmail.com \
    --cc=Simon.Richter@hogyros.de \
    --cc=brauner@kernel.org \
    --cc=david@fromorbit.com \
    --cc=dsterba@suse.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=osandov@osandov.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox