Generate private neuroglancer URL

[JThoennissen]

With this functionality the user is able to generate a private URL to view and share the anchored volume as a remote dataset in neuroglancer-based image viewers.

[xgui3783]

Ping @pacher

We would also need to attached a lot of warning with this function

[xgui3783]

@pacher and I just discussed, and voluba image service now supports GET /share/{filename} endpoint, which returns /shared/{path}, which is a valid neuroglancer precomputed url.

next step is to build the export functionality in voluba

edit: the links will continue to be valid even after user deletes the image from private space. We should make this clear on voluba.

[fsdavid]

@xgui3783 Cannot retrieve shared image. After sharing, I'm trying to get it with {voluba image service}/chumni/shared/{path}. I'm getting Chunk name '{image name}' does not match chunk name pattern error.

[pacher]

@fsdavid What is {image name}? What are you trying to get? shared/{path} is neuroglancer precomputed URL, you can get info json with shared/{path}/info or retrieve a chunk with shared/{path}/{scale}/<xBegin>-<xEnd>_<yBegin>-<yEnd>_<zBegin>-<zEnd> So the service is trying to parse xBegin xEnd yBegin yEnd zBegin zEnd of a chunk from your {image name} and failing to do so.

[fsdavid]

@pacher Thanks. Actually, it works with Neuroglancer, and no more questions about that.

Just another question, for now, users cannot see (endpoint which returns shared by me) or remove images shared by them? So when the user will share an image from Voluba, he/she will see the URL only one time and will not be able to get it after refresh?

[pacher]

@fsdavid Correct.

remove images shared by them

Yes. Shared data is public and somebody might have a link to it which should not just stop working. So there is no "unshare" or "unpublish" functionality by design. We can discuss and change it though.

users cannot see (endpoint which returns shared by me) images shared by them

Good point. We can add such an endpoint if there is a valid use case for it.

We can also mark shared volumes in the list of user volumes, but together with delete button this will lead to a great user confusion. Either users will be afraid to delete shared volumes or the opposite, expect it to be "unshared" after deletion. No amount of explanations, pop-ups and clarifications will help.

he/she will see the URL only one time and will not be able to get it after refresh?

Pressing "share" button, i.e. calling GET /share again for the same uploaded file will produce the same link.

But delete, re-upload and share will assume a new version and produce a different link even for the same file. We hash metadata including the time of uploading, but could switch to hashing of file content if needed.

[pacher]

So there is no "unshare" or "unpublish" functionality by design.

We would also need to attached a lot of warning with this function

Actually, point raised by @fsdavid is a serious issue and we should discuss it in more depth at the meetings. ping @xgui3783

[xgui3783]

So there is no "unshare" or "unpublish" functionality by design.

We would also need to attached a lot of warning with this function

Actually, point raised by @fsdavid is a serious issue and we should discuss it in more depth at the meetings. ping @xgui3783

I think there should be a way for auth user to unshare the volume, even if it breaks some functionalities? (I am saying this, but I do not know how much effort is is required to implement it on the image service side)

semantically, a PUT /share/{item_id} to create a share link, vs DELETE /share/{item_id} sounds fair.

[fsdavid]

Would these features be crucial? If not, first I'll implement a simple share button and then upgrade after discussions.

[pacher]

There might be additional "stop sharing" button in the future, but you can go ahead with a "share" button already. We might also put a time limit on sharing in the future, but that will be just an additional parameter, should not require changing base implementation.

[fsdavid]

Fixing PR: https://github.com/FZJ-INM1-BDA/voluba/pull/146