Enhancement - ability to directly link (permalink) to a specific script

[mendhak]

Hello, great project thanks for doing this.

Enhancement idea - Being able to link directly to a specific script would be a very useful way of sharing scripts with other people. We could just link them to something like https://privacy.sexy/x/y/z and they can always see the latest script there.

[undergroundwires]

Sounds really good. I'm considering a bigger change that'll indirectly allow this.

We could have privacy.sexy/{os}/scripts/{script-name} for each script using vue router. It'll be like a WIKI page where code, revertCode and docs are provided. So the URL of each script will be shareable. Page will also a button to generate a file/run on single script level.

I'm also thinking about adding a single ℹ (removing existing ones) on each script that'll on click redirect to the specific script page and on hover it'll show the documentation text/urls that we have today.

I'll prioritize this after the macOS (multi-os) support. However if someone else wants to take a look and needs assistance just ping me.

[dougg0k]

Hey, I saw more talk on this issue #59 that seemed somewhat related to this.

Is this going to be moving forward?

I noticed that it was removed from milestone.

[undergroundwires]

Hi @dougg0k,

I'm setting this as the next major feature on our roadmap. You can contribute by providing feedback or through donations, it would be greatly appreciated.

Progress so far:

• Markdown documentation support is integrated in 0.12.X, paving the way for future content on these pages.
• Each recent patch update has been loaded with extensive documentation, which will continue to enrich our content on these pages.
• CSS styling for documentation text is implemented. This style will be consistently used across the platform to maintain a uniform user experience.
• The build toolchain/front-end framework has been migrated to the latest versions.

What's next:

1. IDs: Introduce IDs for each script/category #262 needs to be addressed first. Feel free to take a look at the proposed solution and point out any potential anti-patterns. This will be almost impossible to change later, so good to get it right.

2. A new app: In my post from 3 years ago (time goes quick) I was talking about introducing vue-router and extending the existing application. I've realized that the application has grown significantly, now exceeding 1 MB with all its assets. For better user experience and SEO, especially considering users conscious about privacy and JavaScript usage, I'm considering building a new and completely static website without JavaScript requirement. I'm looking at tools like hugo or VuePress. This would involve building code to parse privacy.sexy data into markdown files. Additional custom coding is required for seamless developer experience and integration with the main app. The idea is to host this on a subdomain like wiki.privacy.sexy, which necessitates structural and architectural modifications to the source code. This is essentially creating a new website that needs to blend well with the existing developer/user experience of privacy.sexy.

   Seeking input:

   • Do you think this plan is viable? Any suggestions for simplifying the process? Any best-practices to keep or culprits to avoid?
   • Is wiki.privacy.sexy the best choice for the subdomain? Alternatives like help.privacy.sexy or learn.privacy.sexy are also on the table. I'm open to name suggestions.

3. UI: I have not put so much thought into UI and I would appreciate ideas and feedback on this.

   Seeking input:

   • What's the best way to incorporate permalinks in the UI? Should we add a new button, or integrate it within the existing (i) icons? For reference, support.google.com uses a three-dot menu for link access. I'm wary of UI clutter with additional buttons – your thoughts?
   • Regarding the layout for each script/category page, would this structure work?

       [Button: Go to App Button]
       [Heading: Script/Category Name]
       [List: Breadcrumb Navigation to Parent Categories]
       [Paragraph: Docs/Reference URLs]
       If it's a script =>
         [Paragraph: "Code:" followed by the script code]
         [Paragraph: "Revert Code:" followed by the revert code]
       If it's a category =>
         [Unordered List: Links to Sub-Categories/Scripts] 
     

[dougg0k]

Hey,

Nice, looks good.

I mean, simplifying where exactly in the process, is there anything that is not clear or simple enough?

Subdomain would be your choice, whatever make sense in what you are trying to achieve would probably be the most obvious choice.

I'm not sure there is a right way to implement the permalinks, is whatever make sense in the context that you have and how important would be to be more clearly exposed as an option or not.

You have more experience with your website than I, you should know the answer to the last question.

[Marc05]

I'm very glad to see this feature getting some love. I'll happily donate to show my appreciation for this and the continued development of the project. Thank you!

Regarding the IDs, GUIDs are the right approach. I started to think about how different revisions of the same script could be handled. I thought perhaps a timestamp could be appended to the IDs, then I figured that should simply be left to the tools already available - git. However given the monolithic nature of the collection files, change control for script revisions seems to be cumbersome and scaling is bound to be an issue. A different project structure could help with this. Here are some thoughts on what a different structure could be:

• Script structure
  • 27e7b119 script folder, named as the GUID for the script
    • script.sh script file, well-known name with appropriate file extension
    • doc.txt documentation file for the script with markup syntax
  • Placing the script code in a script file allows for better development quality-of-life with things like code linting, highlighting, etc. Additionally, commenting specific code would be easier. Abstracting the script documentation (e.g. purpose and reference links) allows for the same development benefits such as code highlighting, auto-complete, etc.
• Manifest file
  • The manifest file serves to detail the collection's organization. For instance, it would be similar to the current windows.yaml file, but only contain the necessary script metadata to generate the category hierarchy.

This work could tie into the new 'app', albeit I'm not fully clear on that app's scope. Ultimately however, the focus should be on this much-needed request and its related features. It would be unfortunate for this request to take another two years! As for name suggestions, another is get.privacy.sexy.

[undergroundwires]

Just to update, this is highly prioritized feature from my side. I'm doing small stuff in the background to enable it. I implemented the ID support (#262) and it's on testing phase.

@Marc05, I have been thinking about what you say for a while, and I agree that this will be much better design. I'll move towards to there, everything is so tightly integrated now. I'll decouple the compiler and front-end completely which will simplify things a lot. Compiler will be a CLI tool that will output a JSON (resolving #126 along the way). This JSON will contain everything, docs for the scripts, compiled codes etc. And the current front-end will consume the compilers output. When the compiler is decoupled through CLI interface and stable contract, I can then break down the monolith into the modular and scalable format you suggest without breaking anything. This would allow me to add features that I planned for a while very easily, and enable community to build privacy.sexy derivatives easily.

@plantindesk brought up building the docs pagse using Astro. I looked at it and it seems to be very solid alternative to Hugo. @plantindesk would following flow work?

1. I decouple compiler from application. We call the compiler using something like privacy-sexy-compiler 'dist/app.json'. It generates the JSON file at given path.
2. A custom code developed for building the Astro site will take this JSON file and create different markdown files at src/pages/... for Astro to consume.

I will start working with decoupling the compiler and designing an API for the JSON file once the ID support is well-tested.

[plantindesk]

Ok As you say