nikoPLP
commented
1 month ago The content-type must be passed to nextgraph when the binary is created, and then you can retrieve it when reading the file. it is a string and you can put what you want in it. i thought of using mimetypes as defined for Blob.type but i see Solid is using media-types from IANA, and that they are the exact same. so all is good!
this is not stored as a triple on my side, it is added to some metadata nextgraph stores with the binary. and it is used when the Blob needs to be created on local-first apps. for you it is different as you return the binary content when you receive HTTP GET request. but i guess the HTTP response also needs to set a content-type. so i am just saying you can use what the nextgraph API gives you, and you don't need to fetch the triples to obtain the content-type.
I see that the Solid spec also wants a size, and I do store the size in the metadata too. you get it when you do a file_get. (see file.V0.FileMeta) . But nextgraph does not saves a timestamp. also, you cannot modify the file. but i think it matches your use case and API too (i dont see that you need to modify files)
srosset81
NextGraph support file uploads, so instead of storing the files on the filesystem, we will be able to have them encrypted. We're going to take advantage of this refactoring to improve our compatibility with Solid, by changing our metadata description (we currently use a SemApps-specific ontology).
NextGraph use a special API for file uploading and retrieval. See: https://git.nextgraph.org/NextGraph/nextgraph-rs/src/branch/master/ng-sdk-js/app-node/index.js#L44
Implementation: