Application schemas about handbook HOT 20 CLOSED

I updated the issue description to use "document", "operation", etc

from handbook.

If I think of "traditional" relationship models I would always expect mutable data. For example a post SQL row linking to a profile row via profile_id, I'd expect the profile to be changing over time (email address / username / password updated etc.) or vice versa (post title updated etc.). I will try to think about use-cases where I want to "lock" the refererred data to a certain version..

Yes, this is what I would expect too 👍 it would mean using the document id as the identifier in a relation field instead of the instance.

In the context of again "traditional" relationship models I'm not sure if this is "meaningless". Is the profile_id in the above example "meaningless" just because the referred data might have changed over time?

Yes, sorry, I didn't make that point clearly. What I meant was, that if we are expecting the instance id to point at immutable data, we need to augment it with more graph context (either tip hashes, or author entry seq numbers), as the current id doesn't do that.

from handbook.

for the document_view field we need more than the instance/document-view hash (this id, confusingly, points at mutable data), as we need to be able to recreate the view from a collection of operations (some of which are not related to the view in question). This is where the resurrected vector-clock (of known branch tips identified by hash or author/seq-num pairs) comes in. We would end up with something like:

Ah right, this makes sense 👍 Thanks for clarifying! It could make sense to make this an optional field?

from handbook.

Imagine URLs on the web could point at specific past versions of a web page so they would never break.

This reminded me of IPFS and I've tried to find out how they approach it. Could find this: https://docs.ipfs.io/how-to/take-snapshot/ and this is funny: https://docs.ipfs.io/concepts/file-systems/#mutable-file-system-mfs - so IPFS is immutable by default and then they have these "simulated" mutable environments on top of it :-D

from handbook.

@cafca what I meant here is that, if we do have this magical "reference to an immutable point in a documents history" then we could use it really nicely for our permissions system by referring to a snap-shot of a keygroup documents state. This could be used if we reverse the relationship between keygroup and authorised documents, we could point at the keygroup from an operation. If the author of the operation is a member of the keygroup at that specific point in time then we're all good, this operation is authorised, if not, gooooodbye. Obvs this throws up other problems which would need exploring (how to stop operations pointing at random keygroup states from the past?).

I read something along these lines and it was described as "reversing the graph". By making the leaves/tips of one graph the predecessors (or in our language, previous_operations) of a newly published operation (which could be in a different document, doesn't matter) you are "inverting" the targeted graph, and freezing it's state in place (you can't add new predecessors, which is what the whole graph is now). For us a list of references pointing at tip hashes would do this 🦄

from handbook.

https://wolke.liebechaos.org/apps/files/?dir=/Verein/Projects/p2panda/Meetings&openfile=58986

from handbook.

Me and @cafca (in the context of KeyGroups) ended up discussing relations quite a lot yesterday. Just collecting some thoughts/realisations here:

An instance id (hash of the entry) doesn't tell us very much

• notable as it felt counter intuitive, but an instance (identified by an entry hash) is not a fixed value. A document could easily resolve to two instances both with the same id but which contain different values. Only the tip of the graph needs to be the same for the two instances to have the same id.

In the context of relations, is mutable or immutable data expected

• do we actually want to instead point instead at a Document? This would mean that we are making the relation to mutable data which we will expect to change over time. Important for author-relations where we want to permissions on a document to change as a document is updated. However, we lose the knowledge of what the data looked like when the relation was made (Is this important? When do we need it?)

Instance id is meaningless as it is now

• as we have it now, we have no way to recreate an instance identified by it's id. If we want to be able to do this we need to augment the instance id with extra contextual information about the structure of the graph which that instance was derived from. This would mean also storing every known merged or hanging branch tip which exists in the graph (now we are back to a vector clock like object). This is easily derivable within a document (because of our operations' previous_operations field).

from handbook.

In the context of relations, is mutable or immutable data expected

If I think of "traditional" relationship models I would always expect mutable data. For example a post SQL row linking to a profile row via profile_id, I'd expect the profile to be changing over time (email address / username / password updated etc.) or vice versa (post title updated etc.). I will try to think about use-cases where I want to "lock" the refererred data to a certain version..

Instance id is meaningless as it is now

In the context of again "traditional" relationship models I'm not sure if this is "meaningless". Is the profile_id in the above example "meaningless" just because the referred data might have changed over time?

from handbook.

Yes, this is what I would expect too +1 it would mean using the document id as the identifier in a relation field instead of the instance.

Yes, I think I mean "document id" every time "instance id" pops up (think simply because its name got changed some weeks ago, could be that we have still old files flying around where its named the old way) 👍

Yes, sorry, I didn't make that point clearly. What I meant was, that if we are expecting the instance id to point at immutable data, we need to augment it with more graph context (either tip hashes, or author entry seq numbers), as the current id doesn't do that.

I think I'd need an example of when we need immutable data. Think the mutable case is probably the more intuitive and common one?

from handbook.

Or in other words:

"id" or "instance id" as it was named +1 year ago is the same as "document id" today 👍

one more reason why I think we should NOT use the word instance anymore at all

from handbook.

But generally I like the idea of pointing at the actual, immutable, version of the document in relation fields instead (I guess this would be the "instance" as per our temporary new definition and hopefully soon "document view"). I can't think of a common use-case for it now, but it does not hurt to have it when we need it since we get it almost "for free"?

It could be simply two fields:

relationship:
   document: <Hash>
   document_view: <Hash>

or only the document_view one, but then we need to derive the document manually?

from handbook.

Yes, I think I mean "document id" every time "instance id" pops up (think simply because its name got changed some weeks ago, could be that we have still old files flying around where its named the old way) +1

Actually I think there are 2 different understandings of this still in existence. At least as I understand it @cafca is imagining that we point at a specific instance/document-view here, with the intention of retaining some knowledge of what the data looked like when we created the relation. @cafca please correct me if I'm wrong!

I think I'd need an example of when we need immutable data. Think the mutable case is probably the more intuitive and common one?

Glad you asked, see the final point here: #118 (comment) (I may be wrong though ;-p)

from handbook.

But generally I like the idea of pointing at the actual, immutable, version of the document in relation fields instead (I guess this would be the "instance" as per our temporary new definition and hopefully soon "document view"). I can't think of a common use-case for it now, but it does not hurt to have it when we need it since we get it almost "for free"?

I also like the idea of being able to point at immutable data, my intuition is that it will be most useful in system areas like permissions, I also don't have any concrete examples outside of this yet.

It could be simply two fields:

relationship:
   document: <Hash>
   document_view: <Hash>

or only the document_view one, but then we need to derive the document manually?

for the document_view field we need more than the instance/document-view hash (this id, confusingly, points at mutable data), as we need to be able to recreate the view from a collection of operations (some of which are not related to the view in question). This is where the resurrected vector-clock (of known branch tips identified by hash or author/seq-num pairs) comes in. We would end up with something like:

relationship:
  document: <Hash>
  document_view: <ConcatenatedListOfTipHashes>

from handbook.

Actually I think there are 2 different understandings of this still in existence.

Also agree that this needs some proper clarification and definition somewhere where we all agree on 🥳

from handbook.

I think I brought up the notion that we need to be able to point at a specific version of a document in our convo yesterday so I maybe I should put that into context. I don't think we have to do that, it's optional.

But I think in a collaborative environment it can be quite helpful to be able to do that. Whenever you publish content that depends on context and that context can be changed by collaborators there is the risk of indirectly changing the meaning of your content. The example we used yesterday was a reply-feature (e.g. comments system). You reply to someone with "actually that's wrong" and afterwards they update their comment to fix their mistake, now you look stupid lol. So here it could be nice to be able to offer a feature like "see original version of referenced content". We could also add this later on but then we would have to make it optional. Having it non-optional could be a strong property of p2panda. Another example: Imagine URLs on the web could point at specific past versions of a web page so they would never break.

from handbook.

You reply to someone with "actually that's wrong" and afterwards they update their comment to fix their mistake, now you look stupid lol

Not argumenting against your point as I think it would be a really nice addition to the protocol, just adding some thoughts to it: I very rarely look at the edit history of any message or website, it comes with a higher cognitive load for me, also misunderstandings like this seem to be common and somewhat accepted in social contexts, they are not always fun, but can often be resolved fairly easily, I don't know if technology helps here or might be too abstract for what is actually socially going on. Intuitively I'd still see it as an optional addition, as it puts quite a lot of work and data into every operation and the nodes for a maybe edgy UX case (? that being said from a maybe subjective point of view, don't have any data here).

from handbook.

Thanks, I think these are nice examples 👍

Regardless of which case we want to support in user facing settings (application schema), my main realisation right now was that we need to clarify the two relation cases (mutable or immutable data), where they plan to be used, and how we expect to achieve the second (seeing as instance/document-view id is actually pointing at mutable data).

This has big implications for KeyGroup in particular.

from handbook.

it puts quite a lot of work and data into every operation and the nodes for a maybe edgy UX case

I just went over this discussion again and I am a bit confused :D Are we still talking about having

relationship:
  document: <Hash>
  document_view: <ConcatenatedListOfTipHashes>

this as the content of a relation field? Is this really that much work to do?

and @sandreae what would be the big implications for key groups?

from handbook.

Idea: When deleting an application schema document (via DELETE operation) then it moves into "deprecated" state. The node maintainer can choose themselves if they want to then finally remove that schema (aka "unregister" it), probably through some cool cli or ui.

from handbook.

As long as it's cool, I'm all in!

from handbook.