Feature Request: Gallery-Template for linksharing-service

[TopperDEL]

I'm developing a photo-gallery-app - you might have heard about it. :) With that app users can create albums and upload images from their smartphone into a buckt. They can then share a link to a generated index.html to view that gallery in the browser with others. So far so good.

My main problem now is that the generated URL (e.g. https://link.eu1.storjshare.io/raw/access/mybucket/albumname/index.html) cannot be served due to phishing problems. So I would have to provide an own domain (like storjgallery.de), add some DNS-entries and "wrap" the linkshare-service with my own domain. That works quite good if I'm ok with providing only HTTP-urls. If I want to add HTTPS, things get complicated. As my app uses the access grant of my users and I'm not providing a "gallery"-service, I do not want to host anything here. But to provide HTTPS-URLs for dynamically generated subdomains (like myusergallery.storjgallery.de) I need to provide a SSL-certificate and thus be a proxy between the user and linkshare.io. All traffic would have to go through my service or I would at least have to provide the static parts (like index.html) through my server and load the bigger assets (the images) via gateway-mt.

Long story short: I talked about this with @stefanbenten. And during the discussion we figured out that there might be a quite easy way to get this problem fixed in an elegant way: The current linkshare-service provides a "landing page" if the URL does not contain "/raw/" and leads to e.g. an image. We could utilize this and add another template, that serves as a "base" for a gallery. So if I call the linksharing-url with a specific path or parameter, it would serve me a standard gallery template (like we already created during the hackathon in spring 2021) and load the dynamic content (albumname and pictures to show) from a file within the provided bucket.

In the end it would go like this:

• my app (Android, iOs and such) uploads the user images, thumbnails and the album-definition-file in a specific (tbd-)structure into the storj-bucket.
• the app generates a share-URL like it's possible today.
• the app adds a parameter/path/whatever so the linksharing-service serves a specific html-template, that fetches the details (albumname, images to show) from a file within the bucket (like albumdefinition.json or what) - either by dynamic javascript in the static index.html or via injecting it during serving via the underlying go-routines.
• to make it super-round storj could provide a https-url like "storjgallery.io" and proxy the traffic to the linkshare-service - so the enduser gets a nice-looking url.

In the end, the user could retrieve a URL like the following from the app: https://storjgallery.io/accessgrant/albumname and once the user clicks it, it shows a nice gallery. Only the images are dynamically loaded from the users bucket. The static template-assets might be provided by the linkshare-service like it is done today with the "node-map-template".

This would definitely help alot with the app I develop and make everything quite easy. The effort on thet gateway-mt-service should not be that much.

I would appreciate a discussion whether this is possible or not and if I might get that feature. My app is nearly finished, it's "just" missing that HTTPS-part. It would be awesome to get a clean solution without me having to proxy anything and mess with automatic generated DNS-entries. Thank you!

[jtolio]

This is great!

Out of curiosity - if we instead allowed you to upload your TLS cert in some secure way to your Storj bucket and then we served HTTPS content with your domain's TLS cert, would you prefer that more or less than this? Obviously it's a very different feature than an image gallery, but it sounds like that might have helped with your original plan? What seems like a better feature to you? (whynotboth.gif is totally a valid answer, just trying to prioritize)

[TopperDEL]

We talked about this way, too. This was my first idea - let the user upload a certificate and linkshare serves that for a specific bucket. This would only help partially in my case. First of all I would have to generate a certificate for every subdomain of my users. I could provide a wildcard-certificate - but then comes the next problem: I would need to renew the certificate on a regular basis for all of my customers. That is nearly impossible. Doing this from the users-app is overly complicated and providing a service for that, too. My next idea was what if the linkshare service generates the certificate if I have a specific DNS-entry set - that might work. But @stefanbenten said that it brings other problems as the certificates need to be installed in all instances of the linkshare-service and that makes it again more complicated.

So: for a static site under my control, that might be an interesting way as I would at least not have to host a service just to get https. But then we would need to think about renewing the certificate and that again makes it complicated. So getting a certificate by e.g. Letsencrypt done by your linkshare-service if I have a specific DNS-entry would be a nice addition.

But for my app the template-option with a "normal" SSL-certificate on the linkshare-server would be the best. Combined with a nice-looking URL (like the proposed storjgallery.io or so) would be awesome and all I need. Stefan already has a PoC locally and I'm eager to see it. :)

[kmozurkewich]

I like the idea of templates for the link sharing service. I would like to use something like dotfiles in a path to control and customize the layout and behavior - perhaps even integrate a template framework (mustache, etc.) so users can get creative with the functionality.

[TopperDEL]

I definitely agree! Though I do not know if this would open the doors again for phishing-stuff. If Storj controls the template completely and only add some variability like showing a list of images and such, it is under full control. If the user can replace the entire theme again then I guess we are in the same situation again (though I don't really know how mustache works).

How can we proceed with this? Who is in charge to decide or take action?

[TopperDEL]

Any news on this one? :)

[TopperDEL]

@jtolio @stefanbenten 😢

[stefanbenten]

I do not think there was any progress internally. I'll ask today 👍

[iglesiasbrandon]

Hey, @TopperDEL thanks for creating this issue. We spoke about this during our internal Arch review meeting this morning and the takeaway was for the product team to review this request and figure out where it fits on our roadmap. We are in the process of migrating our ticket tracking to GitHub as well as creating a public roadmap on Github. Once these efforts are more complete we will have a better idea of where this issue falls!

[TopperDEL]

Thanks @iglesiasbrandon for keeping me updated. Let's hope it get's a high priority. :)