Links Page for account users only

[ZicPL]

I'd like to ask for a user account to have two pages.

First - public
Second - for logged in users.

In specific cases, I need to publish links for a small group of users, because for the rest it isn't a useful link. This has two advantages:

• With a large number of Links, I can divide them between these pages, which will be more transparent.
• Publishing links for logged in users improves security. I've an apps whose links I'd not like to make public. Of course, I can forward (Sensitive) Links directly to people, but this application is better.

Let me know what you think 😃

[JulianPrieber]

Love the Idea

[JulianPrieber]

Alternative

I wanted to add one final note:
This feature can be implemented using the new Block System. If the goal is to conditionally hide or display individual links or sections on your main page, you can accomplish this by creating a custom block. This avoids the need to fork and modify the entire project. If anyone is interested in exploring this approach, I’d be glad to assist.

I put together a concept block to showcase this idea, enabling users to create links that are visible exclusively to others within the same instance.

This concept uses a custom link and the new Block System to add this functionality.

To add this block to your instance:

1. Download the latest version here.
2. Upload and unzip the block folder into the blocks directory on your server.
3. The block can then be selected when adding a new link.

Source code

[ZicPL]

@TereyagiTR @Mich3lleV @Mamb4Black @x-g3niu5 @Raph-dK @ArataKuge

Part of the new feature is already here 🔥

[Mich3lleV]

@JulianPrieber 😍
Thank you 🥇

[JulianPrieber]

Based on user feedback, I’ve implemented a new block that includes many of the features suggested here.

I was able to integrate link groups instead of using single links. When adding the block to a page, you can include any number of links, which will then be displayed together in a group.

---

Additionally, the block allows for the specification of usernames that can access the grouped links. You can enter as many usernames as needed, granting access to the selected users. Authenticated users on this list will be able to view and interact with the links within the group.

The block owner and administrators always access link groups.

---

On the LinkStack page, link groups will be displayed like this:

---

This block is still in its testing phase and may contain some issues.

I encourage anyone to try it out and share their feedback.

---

To add this block to your instance:

1. Download the latest version here.
2. Upload and unzip the block folder into the blocks directory on your server.
3. The block can then be selected when adding a new link.

Source code

[TereyagiTR]

I've been waiting for this a long time. I wanted to propose it myself some time ago, but I forgot 😝 Your comment reminded me about this feature. In my opinion, LinkStack will gain from similar apps, because there're many of them. I not programming, but I'd improve this feature:

1. Currently LinkStack has a tab where you enter www addresses and after approval these links will appear on the page (this is how it works now). I'd change mechanism of this settings page to something similar to local Link Database.

2. Next to the input field for entering links, two new fields could be added: 3 checkboxes and input.
   Checkbox:

• Don't Public (Visible only on this settings page);
• Public (as it is now);
• Publish for specific users. After selecting this option, the input field would be enabled.
  Input field:
  Here we enter the Handlers (@username) of users (dedicated lines for them) separated by a special character, e.g. a comma or semicolon.

Additional comments:
It'd be great if by typing @ and 3 letters the app would start suggesting user itself. Don't worry, in account settings each user could decide about their visibility e.g. disable this option -> In this case the app would not suggest the Handler users in this field during entry. You can still publish links to specific users, from now on entering the full names of the users Handlers (without prompts in tooltip). Of course, I understand that I don't know all the users on the server, but I can find out through external: chats, e-mails, SMS, etc.

3. The user who has been granted permissions to see Links specifically for them visits the page with the sharer's links. It's still the same page with public links as now but a special frame would appear (e.g. with a dashed line) containing dedicated links. Below this frame, public links would still be located - there isn't need to create a special tab/page for links because it is the same one page (dedicated links highlighted with a frame).

[JulianPrieber]

While I'd love to make this the new standard, implementing it would require more resources and time than we currently have available for this project.

I've built a small prototype to explore the concept, and I'm hoping to improve it in the future.

However, without additional resources, I can't dedicate the time needed to fully develop it right now.

If all goes well in the future, I'll be able to invest more time into making this.
@TereyagiTR @Mich3lleV @ZicPL

[ZicPL]

@JulianPrieber
I'm watching this very honest conversation. I regret that such wonderful projects don't have enough resources you don't get what it deserve 😭 I think @TereyagiTR and @Mich3lleV haven't expectations for the project/You. We all appreciate Your hard work and would like to see this favorite project of ours continue to grow. I didn't know my topic would become so popular, but I felt I should speak up because the only emotions we feel are gratitude and concern. I suspect that the popularity of this topic is because communities these days are looking for apps that respect their privacy. The ability to publish a private link seems like a natural next step for Your project (Your app would stand out from the competition) - and the FACT that users wrote this in Your project and not others shows great hope in Your project.

[Mich3lleV]

[JulianPrieber]

Thank you for the kind words.

[Mamb4Black]

@JulianPrieber what resources are you talking about? maybe I can help.

[JulianPrieber]

I also believe this project has immense potential, which is why I want to prioritize accessibility and security for the next updates.
The recent updates have specifically focused on addressing security vulnerabilities and backend issues. Tackling these areas is essential before introducing more advanced features.

In parallel, I’ve been working on a prototype aimed at resolving the key issues holding LinkStack back in its current form. I think the best time to add this feature would be in the upcoming version 5.0.0, alongside the much-requested "multiple pages per user" functionality.

Simply put, I don’t want to build a house on a shaky foundation. If that's understandable.

I was curious how much ? You wrote about money, but you didn't give a price.

I can’t provide an estimate without understanding the complexity first. Depending on the exact functionality, many of the core components may need significant changes, which could impact the cost drastically.

If @JulianPrieber wants, I can close this discussion

@ZicPL I'll keep this discussion open until the feature is implemented in some form, as these discussions are essential for keeping feature requests organized. If the current plan changes and the feature isn't added, I'll update the discussion with the appropriate label.

However, I ask to keep this thread focused on this specific feature. For unrelated topics, please consider starting a new discussion in the general category.

[ZicPL]

(..) this feature would be in the upcoming version 5.0.0, alongside the much-requested "multiple pages per user" functionality.

❤️

(..) l keep this discussion open until the feature is implemented in some form, as these discussions are essential for keeping feature requests organized. If the current plan changes and the feature isn't added, I'll update the discussion with the appropriate label. However, I ask to keep this thread focused on this specific feature. For unrelated topics, please consider starting a new discussion in the general category.

I agree with You on all points. Users always see the security problem after the fact when this is critically important.
The atmosphere here is starting to get tense (unnecessary pressure on the owner), so I ask everyone to make technical entries in the discussion (talk about this topic case), e.g. TereyagiTR nicely described the functionality from the user's side (frontend).

I also posted a request in this thread —> https://github.com/orgs/LinkStackOrg/discussions/49#discussioncomment-11398919

@JulianPrieber How do You see the implementation of this feature ?

Your dedication is great, keep it up and it's nice to hear that You already see a version in which this feature could appear.
Best wishes !!

[JulianPrieber]

@JulianPrieber How do You see the implementation of this feature ?

The way I see it, implementing this feature hinges on the ability to create multiple link pages. The core concept is that users should be able to generate multiple "sub" pages, each optionally equipped with a separate profile description, picture, etc.

To make this work effectively, there would need to be specific limits that admins can define, for instance, determining how many pages a user can create or how many links each page can have. While version 4.x.x does not currently support such granular limits, version 5 has been designed with advanced user permissions in mind, making it feasible to implement these controls.

Another key aspect would be giving users control over whether search engines can index their pages. This added flexibility ensures better privacy management and aligns with user expectations.

Once these foundational elements are in place, we can build on the feature by introducing access restrictions. The simplest method would involve allowing users to set passwords for their link pages or enabling access solely via unique links.

For additional functionality, introducing a group feature could be considered. While version 5 would support such a feature, it isn’t currently planned, as it primarily benefits admins rather than end users. Allowing users to search for other users raises privacy concerns, so a more reasonable alternative would be to enable invite-based access. Users could send invites, and once accepted, invitees would gain access to specific pages.

Finally, there’s also the potential to implement a collaborative feature, enabling multiple users to edit a shared link page. This idea has been suggested before and could complement the current design if developed further.

[ZicPL]

Once these foundational elements are in place, we can build on the feature by introducing access restrictions.

From Your entire post, only this is part where I suggest to make a change. Thitle functionality responsible for defining access & visibility of links (for: logged in/not logged in & with password/without pass) isn't related to pages/tabs in any way, but complements each other very well. What I mean by Link Handling (& from context TereyagiTR post too)? It's permissions and visibility level for different types of users.
Ofc, You decide, although it would be nice if You could comment on following arguments:

Feature introduced BEFORE "Creation and Managemen Pages"

Both features added together

The complexity of Link Handling (control -> passwords/no password and visibility -> logged in/no logged in) is lower compared to the Pages Creation & Management feature, which is more expanded and requires more testing. In this case, Link Handling implementation would allow for adaptation in LinkStack and would be sufficiently refined at time of implementation/adding to the Page Creation and Management feature.

Link Handling management in page settings. The users/Admins will experience more benefits from new features when both are available at the same time. Adding these features separately wouldn't intensify the sensations as much by dosing the possible configurations. This would be better to added before Page Creation and Management (mode with link management in pages settings) or at the same time.

I intentionally omitted to introduce the Link Handling feature AFTER "Page Creation and Management" because my experience tells me that the dependence of Link Handling feature on Page Creation and Management carries two serious risks - believe me, the term "Atomicity" is a basic concept that guarantees the reliability of operations as opposed to dependencies.
Please take a look:

1. st Danger. Page Creation and Management will be introduced before Link Handling, but the community will react negatively and want to stop further development of the Page Creation and Management feature. We will never see the Link Handling feature.
2. nd serious Danger. Page Creation and Management will never be completed or will be canceled.
3. rd serious Danger. Work on Page Creation & Management feature will take longer, consume all resources, concept will change or "Link Handling" will constantly change/grow due to new ideas from other users (or any other reason why the implementation of Link Handling will be delayed)
4. th Danger (enough for today). For random reasons LinkStack will stop being maintained. I know, It's strange at this point and it doesn't happen often when things end suddenly, but there have been cases like that in the past.

The final word on this part.
There're rational reasons why Link Handling could have been implemented sooner and faster (e.g. complexity) but I understand and respect Your decision to add feature in LinkStack version 5. I wouldn't make both features dependent on each other. Adding Link Handling at the same time as Creation and Management Pages is a big challenge, but still much better than AFTER (items 1-4). My text seems to be an attempt to persuade You to implement it faster, because I'm trying to convince You with many arguments, but it wasn't fair to me. Yes, I started this discussion, which means I couldn't be considered an objective person, but I think I'm close to a realist. However here is only one big counter-argument: higher priority for "Page Creation and Management" and I don't find more egzamples.

@JulianPrieber What do You think? Do You agree with me?

The simplest method would involve allowing users to set passwords for their link pages or enabling access solely via unique links.

This is a great point, but it is more about "Creation and Management Pages". In a sense, it's the same functionality (hacky?). In this discussion the Link Handling which I described well above and It's at a lower level of abstraction (propably easier), because Feature would be done independently of one (as it is now) or selected page (Creation and Management Pages). The main Concept is about the functionality of the link itself, not where it is located.

For additional functionality, introducing a group feature could be considered. While version 5 would support such a feature, it isn’t currently planned, as it primarily benefits admins rather than end users.

It isn't easy for me to comment. It sounds great and is definitely a powerful solution. Thank You for sharing this info. I only have one question. Can I consider this as a further perspective (plan) for the future? I think that at this stage of discussing the basic goals for "Link Handling" - example you mentioned is far, too far.

Allowing users to search for other users raises privacy concerns, so a more reasonable alternative would be to enable invite-based access. Users could send invites, and once accepted, invitees would gain access to specific pages.

I agree. This is a great idea. Invitations are independent of whether Visitors have own account in the instance LinkStack or not. I see only one thing would only be necessary to limit the validity period for non user, so that the link shouldn't forever available those out of instance - otherwise the feature would be pointless.

Finally, there’s also the potential to implement a collaborative feature, enabling multiple users to edit a shared link page. This idea has been suggested before and could complement the current design if developed further.

High interactivity of objects with real people is often presented as immersion. Depending on which way You go, it can be trivial or very advanced, but I can't help or advise here :-( It looks like You have a goal for LinkStack version 6 ☺

I'm not often active in discussions, and on Github I don't even remember it. I would appreciate Your understanding if I wasn't as active for various reasons.

in touch 👋

[JulianPrieber]

Clarifications and Goals for LinkStack

Context: My Approach to Feature Planning

My Approach to Feature Planning

1. Original Vision vs. Current Direction The primary focus of this project has always been to create a personal links page. This goal has remained consistent, even before I became the sole maintainer. However, I’ve observed a growing misalignment between the original intend for this project, what the community and myself now expect. My current aim is to focus on the core fundamentals of LinkStack, aligning its capabilities with the demands needed to take it to the next level. 2. Challenges with the Current Codebase LinkStack has outgrown its original design. The existing codebase faces fundamental limitations that make it impractical to continue building on it in its current state. As such, I believe it is no longer beneficial to extend the current framework without significant changes. 3. Plans for Version 5.0 This new version represents a complete rewrite. A fresh start with a core system designed specifically to meet LinkStack’s evolving purpose and potential. Summary of Vision for LinkStack The goal is to match or surpass platforms like Linktree in certain aspects by refining existing features and laying a strong foundation for advanced functionality. Version 5.0 will reflect this vision with a broader scope, guided by community input and feedback. Feature Planning Philosophy Strategic Dependencies The planning process prioritizes features based on their interdependencies and compatibility with already planned features. For instance, features like multiple links pages are aligned with both user requests and planned enhancements. Core Focus Groups Initial improvements will target three main user groups: Self-hosted Public Instances Government or Educational Institutions Companies These groups have provided valuable feedback that is shaping the roadmap for future releases. Moving Forward The overarching aim is to improve functionality, accessibility, and scalability for all users. With version 5.0, we aim to create a flexible and robust platform capable of exceeding expectations across diverse use cases.

I currently view additions like this within the context of the feature set planned for version 5. This perspective changes both how and if these changes can be applied to the current state of LinkStack.

While it’s possible to implement some aspects of this feature in the current version, it would require omitting certain elements.

For example:

• Restricting access: It would be straightforward to limit access to a user’s links page so that only logged-in users of the instance can view it.
• Password protection: Adding password protection to a user’s links page is another feasible option.

Introduction and Dependency

The way I currently have things laid out, the best way I see to implement this is to introduce the Link Handling feature after the "Page Creation and Management" feature, or introduce both features simultaneously.

As I’ve mentioned before, I always consider changes in the context of other features that can be combined or depend on each other. The consequence of this approach is that the Link Handling feature will be delayed further.

Dangers

While I do agree that the current direction I want to steer LinkStack towards does pose some risks, I still believe it is the best path for the project as a whole.

1. st Danger. "Page Creation and Management will be introduced before Link Handling, but the community will react negatively and want to stop further development of the Page Creation and Management feature. We will never see the Link Handling feature."

There are ways to compromise and get this feature working within the v4.x.x framework, and I’d love to hear some ideas aimed at this. My primary goal right now is to bring the capabilities of v5 to the same level as the current version, but with an improved framework, better visuals, accessibility, and compatibility. This requires that both the Page Creation and Management and Link Handling features be delayed until the core elements are ready.

2. nd serious Danger. "Page Creation and Management will never be completed or will be canceled."

While this is certainly a possibility, I see no reason to consider it a likely outcome, as doing so would not affect the current timeline.

3. rd serious Danger. "Work on Page Creation & Management feature will take longer, consume all resources, the concept will change, or 'Link Handling' will constantly change/grow due to new ideas from other users (or any other reason why the implementation of Link Handling will be delayed)."

This is a valid concern, and I 100% agree with it. I'm actively trying to mitigate it. Feature creep is a serious issue, and 5.0 is designed with that in mind. The main focus right now is to improve the core components.

I’m not 100% set on making Link Handling dependent on whether multiple link pages will be added, but I do believe that this feature would benefit significantly from its addition.

4. th Danger (enough for today). "For random reasons, LinkStack will stop being maintained. I know, it's strange at this point, and it doesn't happen often when things end suddenly, but there have been cases like that in the past."

This is a valid concern, though I don’t see it happening anytime soon. I have clear plans to move this project forward, but I believe it’s not feasible without first addressing several critical issues.

Context: Maintenance Challenges

Maintenance Challenges

Maintenance Challenges In its current state, LinkStack is very hard to maintain. The codebase needs substantial improvement. Specifically: Backend issues: The backend requires better organization, and core components need to be rewritten to enhance maintainability, security, and performance. Codebase quality: The project doesn’t follow the standards it should, and I can no longer justify maintaining it in its current form. This project has evolved through multiple developers, and the codebase was never designed to support a project of this scale and complexity. While I’ve already made improvements to certain aspects of the backend, I don't feel comfortable adding new features to the app without addressing these foundational issues first. The Need for a Rewrite In my opinion, it would be more time-efficient to rewrite the entire project with these core concepts in mind than to continue fixing the existing code. The frontend also needs significant attention. With the new codebase I’m working on, I’ve already laid the foundation for a redesigned frontend that will improve layout, accessibility, and compatibility. This new design is intended to work seamlessly across all devices. Increased Demand and Expectations Given the scale of this project, LinkStack is already being used by businesses and educational institutions like universities. Hundreds of thousands of users rely on it for personal link sites. As the demands on this software have grown significantly since its inception, the current state of the application can no longer meet the expectations of these users. Moving Forward: Version 5 To ensure the survival and relevance of this project, Version 5 must be completed in some form. A healthy project needs proper standards and the ability for contributors to engage easily, which is crucial for long-term success.

Accelerated Implementation

I welcome further discussions and input on how to implement this feature. The way I plan to introduce this feature, its implementation depends on other systems being added first. However, I'm open to alternative approaches that might work better.

There are certainly implementation options I haven’t considered yet, and I’d love to hear other thoughts. Input on what this feature should do, how it should look, or how it should function will help in shaping a possible timeline for its implementation.

Alternative

I wanted to add one final note:
This feature can be implemented using the new Block System. If the goal is to conditionally hide or display individual links or sections on your main page, you can accomplish this by creating a custom block. This avoids the need to fork and modify the entire project. If anyone is interested in exploring this approach, I’d be glad to assist.

[JulianPrieber]

@ZicPL, I truly appreciate your commitment! I’d love to connect and share updates on the development of version 5.0, while also gathering your thoughts on other aspects of the project.

My approach to development has been deeply influenced by insights from our core team, beta testers, supporters and the wider community.

If you're interested in contributing in any way:

I invite everyone to collaborate with us on our Discord server, where we actively plan and refine features as they are being developed.

[ZicPL]

Companies, Universities always use "free" software, whether due to lack of funds or greed (cunning). The advantage of an application with a free license and open source code is huge target group of users. People like me avoid closed applications for many reasons (unknown security, impossibility of discussion, lack of activity, high costs). Universities and Corporations benefit from this fact, but depriving them of the ability to use the software will reduce the chances of them supporting the Creator (e.g. by delegating their employee/student to help, or by financially supporting). Projects on Github, e.g. Piwigo, offer their software for free to everyone, but cooperate with everyone, ask for donations (they have patrons), offer their instance on their infrastructure for a small fee (depending on the level of support). If owner/devteam of the app/project on Github takes care of correct development path, he/she will be successful in every aspect, but above all he/she certainly becomes a target for CTOs from big brands (They would like to have this person on their team). I think you are aware of this (and what I wrote is just a formality).

At this point of the discussion let's pause. The conversation is at a high level and I'll quote what we agree on:

1. Work on the current version of LinkStack is a brake for You.
   ► I think You should immediately end development work and announce a roadmap for version 5. I have participated in such difficult decisions in the past, but changing technology, mature approach to the same topics forced such critical changes.

2. According to item 1. "Link Handling" should be implemented in version 5 of LinkStack, because working on this feature in current version may not be profitable.
   ► I don't know when You want to release version 5 of LinkStack, but if it happens in a few months then let's not consider the current version for adding this feature. I confirmed this in previous message. If this is a distant prospect of half a year or more then I wouldn't hold back from implementing this feature for the current version. Getting to know the schedule prototype would explain a lot.

3. The "Link Support" feature is basic, atomic, independent, but in combination with other functionalities it shows greater potential.
   ► In my last message I agreed with Your concept of this feature:
   a) Access to the field (including the link) is password protected. The field/Link is visible to EVERYONE (does not require invitations), but without a password You do not have access to it.
   b) Visibility of the field (including the link) on the LinkStack users page. Without receiving an invitation EVERYONE will not see and have access to the Link. The person who receives the invitation sees the field (including the Link) as standard.
   c) Visibility of the field (including the link) with the password on the LinkStack users page. The same as in point b), but additionally after receiving the invitation You must enter the password, otherwise You will still not have access.
   d) Visibility of the field (including the link) ONLY for logged in LinkStack users. This is the same as b), but in this case You don't need to send invitations (automatic access).
   e) Visibility of the password field (in this link) ONLY for logged in LinkStack users. This is the same as d) (no need to send invitations to see fields (including the link), but without a password You still won't have access.

I think the 3 sub-items above contain all use cases and none of them require the "Page Creation and Management" feature.

@JulianPrieber , is that all? I don't think I left anything out. Do You agree with the above?
Of course, the above 3 points are my suggestion and they can be combined with another feature or expanded with properties such as:

• invitation validity time, passwords
• limiting link clicks
• etc.

Learning about the plans for Linkstack version 5 will allow me to speak more precisely. Will it still be possible to install the app from source on own Hosting supporting the LAMP stack? In the past, the corporations I worked for clearly put up a wall for new development needs (business) of the old application. I advise You to do the same, and take action only in the event of a critical security threat.

I've started using Discord (3 months) and the Linkstack group is the 1st one I've joined ☻ I just saw a message from a member of group : Be***b (is that someone from Your Team?). I also now see that you've put the feature implementation at the beginning of the discussion. I'll be happy to test this implementation, but to sum up this post, I hope that it has regularized the content.

[JulianPrieber]

1. Work on the current version of LinkStack is a brake for You.
   ► I think You should immediately end development work and announce a roadmap for version 5. I have participated in such difficult decisions in the past, but changing technology, mature approach to the same topics forced such critical changes.

I cannot provide a roadmap for version 5 right now. Version 5 hasn’t even been officially announced yet; it has been in planning for around one year now. Version 5 will require a significant time investment, and I simply cannot undertake it in my free time alone. Throughout the planning phase for version 5, I’ve been applying for development grants to allow me to work on this project full-time. The EU actively supports numerous projects similar to this one, and I believe leveraging that support is the most effective way to take this project to the next level.

To realize version 5 as planned, I need to be able to allocate a guaranteed amount of time to complete the planning stage and build a roadmap. Without this, I would have to compromise on many aspects of version 5.

---

2. According to item 1. "Link Handling" should be implemented in version 5 of LinkStack, because working on this feature in current version may not be profitable.
   ► I don't know when You want to release version 5 of LinkStack, but if it happens in a few months then let's not consider the current version for adding this feature. I confirmed this in previous message. If this is a distant prospect of half a year or more then I wouldn't hold back from implementing this feature for the current version. Getting to know the schedule prototype would explain a lot.

I have no time estimation for version 5. Initially, I proposed version 5 might release around February 2025, but this will not be possible. Since then, I’ve refined the plans further, and I’m very happy with the direction.

I want to prioritize the long-term success of LinkStack over short-term improvements.

The idea of the last updates was to make LinkStack more expandable without modifying the existing core parts of the app. The problem I face now is that adding new features to LinkStack in its current form makes it harder to maintain and may introduce additional issues. Since version 5 is a complete rewrite of the codebase, adding to the current version would increase the amount of work required for version 5.

Even if this approach means pushing new additions further back, I believe this will turn LinkStack from its current prototype-like state into proper, stable production software. I think the outcome will be worth it compared to making drastic compromises.

---

3. The "Link Support" feature is basic, atomic, independent, but in combination with other functionalities it shows greater potential.
   ► In my last message I agreed with Your concept of this feature:
   a) Access to the field (including the link) is password protected. The field/Link is visible to EVERYONE (does not require invitations), but without a password You do not have access to it.
   b) Visibility of the field (including the link) on the LinkStack users page. Without receiving an invitation EVERYONE will not see and have access to the Link. The person who receives the invitation sees the field (including the Link) as standard.
   c) Visibility of the field (including the link) with the password on the LinkStack users page. The same as in point b), but additionally after receiving the invitation You must enter the password, otherwise You will still not have access.
   d) Visibility of the field (including the link) ONLY for logged in LinkStack users. This is the same as b), but in this case You don't need to send invitations (automatic access).
   e) Visibility of the password field (in this link) ONLY for logged in LinkStack users. This is the same as d) (no need to send invitations to see fields (including the link), but without a password You still won't have access.

I’d be willing to implement some version of this feature if it’s possible to do with the Block system. However, there are some limitations with this approach that need to be considered.

Currently, the Block system is designed for individual links, so this feature would need to align with that concept. For example, the Block system could conditionally show certain links based on variables, such as whether the user is logged in, only to specific users, or if individual links that are password-protected.

It may also be feasible to apply this feature to link sections instead of individual links.

If you or others agree that this is an approach worth considering, I’d like to get more into the specifics of how this feature would be laid out. 

---

Learning about the plans for Linkstack version 5 will allow me to speak more precisely. Will it still be possible to install the app from source on own Hosting supporting the LAMP stack? In the past, the corporations I worked for clearly put up a wall for new development needs (business) of the old application. I advise You to do the same, and take action only in the event of a critical security threat. 

 If your question is whether LinkStack will stay open-source, the answer is yes. In its current form, LinkStack will remain PHP-based. Accessibility in terms of easier deployment is a major consideration of mine. I think open-source and LinkStack go hand in hand and are core aspects that set us apart from proprietary platforms with similar features.

---

I've started using Discord (3 months) and the Linkstack group is the 1st one I've joined ☻ I just saw a message from a member of group : Be***b (is that someone from Your Team?). I also now see that you've put the feature implementation at the beginning of the discussion. I'll be happy to test this implementation, but to sum up this post, I hope that it has regularized the content. 

That is my personal Discord account, and you can reach me there if you need to.

I can also send you more details about version 5 if you’d like, though nothing is finalized yet and everything is subject to change.

@ZicPL, if you wish to contribute to the development effort, I can assign you a team member role on Discord, which will grant you access to the development channels.

[ZicPL]

If you or others agree that this is an approach worth considering, I’d like to get more into the specifics of how this feature would be laid out.
I've tested your "hidden links" extension for LinkStack. I confirm that it works correctly. I think that in current version, the implementation of this feature in Block system is the optimal solution.

The whole discussion covers the following topics:

• Link Support (feature) in the current LinkStack version;
• Link Support (feature) in the new LinkStack version 5;

The important terms of the content are:

• The upcoming LinkStack version 5 allows freedom in designing the feature (Link Support) during the planning stage. Building the feature for the new version has two goals: maintaining independence (atomicity) and strong correlation with other upcoming features.
• The current LinkStack version has limitations and "small development" is possible within the "Block system" (the reasons are known and if someone is reading this point, please read the rest of the conversation).

@JulianPrieber Do you allow:

1. Adapt the current thread (discussion) to the needs of the future version 5. "New feature: Link Handling - Design [goals, dependencies, problems] for the future LinkStack"

2. Rename your extension "hidden-link" to "LinkStack Extension - Link Handling".

Splitting the Feature into two topics (too expensive to maintain the same development of both models) will allow to keep this discussion open to new ideas, and your extension to specific conditions (cost reduction).

That is my personal Discord account, and you can reach me there if you need to.

I can also send you more details about version 5 if you’d like, though nothing is finalized yet and everything is subject to change.

@ZicPL, if you wish to contribute to the development effort, I can assign you a team member role on Discord, which will grant you access to the development channels.

It's good that you wrote because Discord has a chat and I can conveniently send an idea which doesn't require discussion on Github.

I'm in Computer Networks and NVME-of Data Centers with adopt future File Systems now. Sometimes in security have to do. LinkStack has served me for personal purposes (reducing the load on my website from menus to keep it simple) and helping my family navigate since they have different IT skills. Linkstack's link support gives me more control over sharing private resources.

If I could be useful to your team, it would probably not be through coding (I code occasionally for my own use), but as a consultant (or a tester on a small scale). I think we can talk about this on Discord.

Coming back to what I wrote above, let me know what You think about splitting and renaming this discussion from the new project You created.

[JulianPrieber]

To keep it brief, I recommend we put version 5 aside for now and concentrate on the block version.

I prefer "hidden-link" over "Link Handling," as the block name should clearly convey its function to the user.

Let's proceed by gathering key points and features for this block, then prioritize them based on feasibility and importance.

---

Anything related to the block's features can be added here: https://github.com/orgs/LinkStackOrg/discussions/804#discussioncomment-11509246

[JulianPrieber]

Block

• Show link to authenticated users only

---

Please suggest any ideas below.

[Mich3lleV]

for me too 😀

"password-protecting links"

I would have never thought of that. That would be amazing.

[ZicPL]

Block

* [x]  Show link to authenticated users only

Please suggest any ideas below.

I've just tested "protected-link-group". I think multiplying "hidden-link" is a great idea. Tell me what You think about:

1. Adding icon inside a frame (border), e.g. a heart in the upper left corner. This would look great for icons representing a specific group of people, e.g. a house symbol -> family group or a star -> premium symbol. Support for .apng or .gif files would be great.

2. The appearance of frame (border) and background could be configured by user, e.g. 1px, dashed, red and background 0.5 transparent. Number 0 turns off frame (border) or background.

3. It would be nice to be able to change the order of links in UI. Currently, You have to manually change the text (e.g. copy / cut).

4. The appearance of buttons could have its own separate style.

[Jeroslav]

Based on user feedback, I’ve implemented a new block that includes many of the features suggested here.

I was able to integrate link groups instead of using single links. When adding the block to a page, you can include any number of links, which will then be displayed together in a group.

Links show a padlock icon but It will be better to be able to decide what icon to set.

1. Adding icon inside a frame (border), e.g. a heart in the upper left corner. This would look great for icons representing a specific group of people, e.g. a house symbol -> family group or a star -> premium symbol. Support for .apng or .gif files would be great.

Padlock icon would fit best here. Selecting one of several default ones, e.g. padlock, house, star, etc. is that it? Each section of protected links would have its own symbol, which would be practical for a few such groups, I think.

[JulianPrieber]

My approach for now is to improve existing and build-on/add to the core features of the block. I'm considering adding a password protection option to the block so non-authenticated users could also access protected links.

I would also like to improve the frontend design on the LinkStack page a bit more, any suggestions or examples are welcome.

I'm prioritizing features that can be added using or reusing pre-made components. Anything else would likely take too much time for now.

Features and Considerations:

• Icon Frames with Custom Borders

Adding an icon is easy, but creating a UI for selecting an icon is out of scope for this feature. (Maybe a pre-selected list with Font Awesome is possible.)

• Configurable Frame and Background Styles

I want to update the styling as I’m not happy with the current implementation, but adding UI for the user to select styling is also out of scope.

• Reorder Links via UI

That’s a key feature already on my list, and I plan to implement this.

• Independent Button Styling

This is probably out of scope for this block. I can adjust the default styling, but adding custom styles for users is likely beyond what I can manage for now.

[ZicPL]

Adding an icon is easy, but creating a UI for selecting an icon is out of scope for this feature. (Maybe a pre-selected list with Font Awesome is possible.)

Font Awesome 👌

I want to update the styling as I’m not happy with the current implementation, but adding UI for the user to select styling is also out of scope.

In my case you don't have to create an interface for editing the style of the frame (border). If you could give a unique ID to each "protected-links" group. I will edit the .css file myself and adjust the frame to my needs.

That’s a key feature already on my list, and I plan to implement this.

❤️

This is probably out of scope for this block. I can adjust the default styling, but adding custom styles for users is likely beyond what I can manage for now.

In this case it's enough that these "protected-links" have a common class in .css - different than other links, e.g. Custom Link, discord, etc.
@Jeroslav suggested adding icons. Maybe add a separate Font Awesome here too ? ;] The padlock can be confusing in some cases. The padlock would be ideal for password-protected links (it would block the possibility of a padlock for other types of links).

Thank You for Your feedback - it's very helpful.