Re.1 yes, that would be what I'd have to do to implement it in the proxy. That or do req/response to the backend (might actually be faster).
I'm trying to understand why the timeline refs though in the first place. It being so loose, would not really add much to "things being out of context" in a potential fork (because other events could still be mixed into the timeline and be indistinguishable from the original) When I start thinking about why it would be needed I can't come up with a scenario where this loose coupling is any better than just the created_at timestamps. Seems like it adds complexity that could be avoided. Relays can just have a small time window of 5-10 min. Overall, it seems like it is a fun experiment to have these references but with little benefit as it cannot be a true chain of events (where every event references the previous like a blockchain would), so I just want to point this out.
Aside from the un-necessary complexity it could be seen as a 'western version' of air replies. By referencing previous events, this could be seen as a reply (and treated as such by a client), therefore breaking the Japan social contract of air replying. It is rude to reference the previous events if it is seen as the expectation of a response.
If the timeline is optional (could vs. should), then I have no problem with it. As currently written it sounds like a requirement.
As for the rest, it does seem like 29 could be a useful pattern to get off the main kind 1 tracks and have a standard way of moderation/invites/group management.
cloud fodder
npub10np…tl5h
2024-07-06 19:18:42
in reply to nevent1q…u8yu
Author Public Key
npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5hPublished at
2024-07-06 19:18:42Event JSON
{
"id": "9eb323d3bc18fef8ea0d83105ed9720f8de5fec74740c654fb49822de915ea0a",
"pubkey": "7cc328a08ddb2afdf9f9be77beff4c83489ff979721827d628a542f32a247c0e",
"created_at": 1720286322,
"kind": 1,
"tags": [
[
"e",
"0348a66ff5586842df16ffa97e03864c1d5f95f05325f4673680ecdd645ae32a",
"",
"root"
],
[
"e",
"68544145ed1d2e3e39b0c86351bfc05c969a8c431e672c8d7bd7f413e10e2f77"
],
[
"e",
"cb542c5ca54d515381e5665dd8def30a5c83aa42a981bba0cb12989773ecf5b9",
"",
"reply"
],
[
"p",
"7cc328a08ddb2afdf9f9be77beff4c83489ff979721827d628a542f32a247c0e"
],
[
"p",
"c5cfda98d01f152b3493d995eed4cdb4d9e55a973925f6f9ea24769a5a21e778"
],
[
"p",
"50809a53fef95904513a840d4082a92b45cd5f1b9e436d9d2b92a89ce091f164"
],
[
"p",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
]
],
"content": "Re.1 yes, that would be what I'd have to do to implement it in the proxy. That or do req/response to the backend (might actually be faster).\n\nI'm trying to understand why the timeline refs though in the first place. It being so loose, would not really add much to \"things being out of context\" in a potential fork (because other events could still be mixed into the timeline and be indistinguishable from the original) When I start thinking about why it would be needed I can't come up with a scenario where this loose coupling is any better than just the created_at timestamps. Seems like it adds complexity that could be avoided. Relays can just have a small time window of 5-10 min. Overall, it seems like it is a fun experiment to have these references but with little benefit as it cannot be a true chain of events (where every event references the previous like a blockchain would), so I just want to point this out.\n\nAside from the un-necessary complexity it could be seen as a 'western version' of air replies. By referencing previous events, this could be seen as a reply (and treated as such by a client), therefore breaking the Japan social contract of air replying. It is rude to reference the previous events if it is seen as the expectation of a response.\n\nIf the timeline is optional (could vs. should), then I have no problem with it. As currently written it sounds like a requirement.\n\nAs for the rest, it does seem like 29 could be a useful pattern to get off the main kind 1 tracks and have a standard way of moderation/invites/group management.\n",
"sig": "7147fda647d445980301f9d18e56737c6ed0adb5bb2676fb3ae6232c1a9e1b56ccfc729671c9574531777d7f716f3270a2ac54c6e6e3058e892d72a8ca7e9467"
}