Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use UUIDs for LDP containers and AS collections #1266

Open
srosset81 opened this issue May 29, 2024 · 0 comments
Open

Use UUIDs for LDP containers and AS collections #1266

srosset81 opened this issue May 29, 2024 · 0 comments

Comments

@srosset81
Copy link
Contributor

NextGraph needs to know a document's UUID to access it, because it is a cryptographic key. To avoid having to maintain an index between the URIs of containers/collections and their document UUIDs, the most resilient way would be to use UUIDs for containers and collections as well. Thanks to TypeIndex, we have a simple way to map a container with the type of data it contains.

It means that, with NextGraph, the only resource or container that will NOT have a UUID will be the WebID (we will use the AccountService to find the document UUID)

Implementation:

  • Add an option to LdpService to ignore slugs. This option will be mandatory if using NextGraph.
    • If true, we will use UUID
  • Adapt the ControlledContainerMixin
    • Since the mixin won't know the path anymore, it will need to find the container UUID on start.
  • Adapt the Inbox and Outbox services
    • Currently the /inbox and /outbox paths are the only hard-coded routes, because they can both be POSTed to. If we keep them as special collections, we will need to store their UUID somewhere. If we consider them as normal collections, we need to refactor this code to handle POST on this kind of special collections.
  • Tool to migrate all containers and collections to NextGraph
    • Very similar to what we plan to do for resources. Could be done at the same time.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant