You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That's a cool idea. Before we get into the content of such a profile, we'd need to think about it architecturally. Librislog is self-hosted by its users. So if we implement the share page locally in Librislog, it's only reachable within the network where the Librislog instance is reachable. That means: if a user's Librislog instance is only on their LAN, friends in the same LAN could view the profile. To share it with the world, each operator would then have to make sure the page/path gets routed to the internet. Would that be a solution in your interest?
Alternatively, we'd need to implement a central service that I, for example, could host on one of my servers. Librislog would then only feed profile information to that server, and the server – sitting on the internet – would serve the profile pages. That way Librislog instances could stay protected in private networks, while users could still host public profiles they can post on the internet. However, that would mean user data goes to an external service. I'm not sure whether that's in line with the self-hosted community. We'd probably need to include a big disclaimer here.
Which solution did you have in mind?
@DawidGardzinski Just adding you here so you see my reply – looking forward to your take on this.
I had the first, fully self-hosted approach in mind.
I think it would be best if Librislog simply provided a public/shareable profile page locally, and it was up to the instance operator to decide whether and how to expose it to the internet - for example through a reverse proxy, tunnel, VPN, or only within their LAN.
That keeps Librislog independent of any central service and avoids sending profile data to a third party. Users who want a publicly accessible profile can configure that themselves, while users who want to keep everything private don't need to change anything.
A central hosted service could perhaps be an optional solution later, but personally I'd prefer the core feature to remain completely self-hosted.
Activity
codebude commentedon Sep 4, 2026
That's a cool idea. Before we get into the content of such a profile, we'd need to think about it architecturally. Librislog is self-hosted by its users. So if we implement the share page locally in Librislog, it's only reachable within the network where the Librislog instance is reachable. That means: if a user's Librislog instance is only on their LAN, friends in the same LAN could view the profile. To share it with the world, each operator would then have to make sure the page/path gets routed to the internet. Would that be a solution in your interest?
Alternatively, we'd need to implement a central service that I, for example, could host on one of my servers. Librislog would then only feed profile information to that server, and the server – sitting on the internet – would serve the profile pages. That way Librislog instances could stay protected in private networks, while users could still host public profiles they can post on the internet. However, that would mean user data goes to an external service. I'm not sure whether that's in line with the self-hosted community. We'd probably need to include a big disclaimer here.
Which solution did you have in mind?
@DawidGardzinski Just adding you here so you see my reply – looking forward to your take on this.
DawidGardzinski commentedon Sep 5, 2026
I had the first, fully self-hosted approach in mind.
I think it would be best if Librislog simply provided a public/shareable profile page locally, and it was up to the instance operator to decide whether and how to expose it to the internet - for example through a reverse proxy, tunnel, VPN, or only within their LAN.
That keeps Librislog independent of any central service and avoids sending profile data to a third party. Users who want a publicly accessible profile can configure that themselves, while users who want to keep everything private don't need to change anything.
A central hosted service could perhaps be an optional solution later, but personally I'd prefer the core feature to remain completely self-hosted.
codebude commentedon Sep 10, 2026
@DawidGardzinski profile functionality was implemented in #101. I would love to get your feedback.
DawidGardzinski commentedon Sep 11, 2026
looks great:
tiny issue:
link is barely visible on dark theme
spaces between elements are too small
codebude commentedon Sep 11, 2026
I'll put your feedback to my todo list. Thus I'll open the issue again.
codebude commentedon Sep 13, 2026
I raised contrast by changed colors and added some spacing in #103