✨ Hide visibility of check-ins for individual users

[VXGP]

This new feature allows you to prevent individual users from seeing specific check-ins. This can be customized for each check-in individually. Users added to a check-in via this feature's menu will not be able to see that check-in on the user's "En Route," "Dashboard," or "Profile" pages.

see #4242

[VXGP]

Ich sehe, dass der Test unter anderem wegen der Datenbank fehlschlägt. Bei meinem lokalen Test hat allerdings alles funktioniert. Wie ist dieses Problem zu lösen? MfG.

[MrKrisKrisu]

Did you push all the files? At least one file is missing, e.g., the migration.

[VXGP]

e.g., the migration.

Possibly I forgot it! I will look for the missing files as soon as I am back home. :)

[VXGP]

All files should now be uploaded. @MrKrisKrisu

[VXGP]

I see that a check is still failing, which is strange since everything starts normally in my local instance. What can I do? @MrKrisKrisu

[VXGP]

I've added the last missing file that I have forgotten, sorry!

[VXGP]

I think everything should be okay now. @MrKrisKrisu :)

[VXGP]

With the last commits I fixed all "quality standard" issues. @MrKrisKrisu

[MrKrisKrisu]

With the last commits I fixed all "quality standard" issues. @MrKrisKrisu

Unfortunately, I won't be able to review this PR over the holidays. Perhaps someone else here has time, or you will need to wait until next year.

[VXGP]

I won't be able to review this PR over the holidays

All good, I have no problem waiting. I wish you happy christmas days. ^^

[MrKrisKrisu]

Just dropping some screenshots of the current state here:

[MrKrisKrisu]

This is explicitly not a review yet, I just skimmed through it, but here are a few comments:

1. In my opinion the UI is a bit toooo overloaded with this big component at the bottom. Even before, I thought it was chaotic, but now even more so. It takes up too much space.

2. Did you test your PR before requesting a review? The feature don't work for me at some points.
   -> for example: The model structure doesn't match the migration, so we cannot save to the table of hidden users. The Model try to save an uuid (which is good!) and the migration creates an id with unsigned big integer.

[VXGP]

Hey @MrKrisKrisu, I think now the PR is ready for review again.

[VXGP]

With the last commit I fixed the missing spaces at line 75 in "DashboardController.php". Now all "quality standards" should have been met. @MrKrisKrisu

[VXGP]

If I may ask @MrKrisKrisu, how long does it take to review a/the change? It has now been a week since I submitted the final commit. Since then, there has been no response from your side. And please don't get me wrong, I don't want to put any pressure or anything, but I'm just personally wondering how long the review will take. 😅

[MrKrisKrisu]

Hello @VXGP... Please note that Traewelling is a leisure project, which is why I cannot guarantee anything.

This pull request continues to be unmotivating for me because I personally do not want this feature. See discussion #4242, where I have already made it clear that I do not want this feature, but that you are free to create a pull request if you wish.

So far, apart from your request, I have only seen negative feedback about this feature, so I currently assume that there is no demand for this specific feature within the community. (see comments from @HerrLevin and reactions via thumbs up on the comments in the discussion #4242)

[VXGP]

Thanks, I understand that this can take time. However, I think there might be a misunderstanding here, and I want to clarify it to avoid talking past each other.

As I currently understand it, the pull request will not be reviewed at all. Please correct me if that’s wrong. My assumption was that it would be reviewed once you have the time, even if that happens later.

Initially, my understanding was that @HerrLevin considered this feature too complex and the UI too overloaded. Based on that, I was honestly surprised when I ended up implementing a fully functional feature anyway. I developed this entirely in my free time, which required significant effort and caused quite a bit of extra work and problem-solving on my side.

I proceeded with this because I was explicitly told that I am free to open a pull request. My assumption was that if I take full responsibility for the backend and the general implementation, the feature would at least receive a proper review for potential merging. If this feature is fundamentally unwanted, I’m struggling to understand why I was encouraged to create a pull request and invest roughly two weeks of work into it.

Regarding the feedback: the thumbs-up reactions currently come from only three users, including you, @MrKrisKrisu. As we both know, the Traewelling community is significantly larger, and I strongly believe that many more users would find this feature useful once they are aware of it.

IMPORTANT NOTE: This is not meant as a personal criticism or attack in any way, but purely to clarify expectations and avoid misunderstandings on both sides.

[MrKrisKrisu]

I'm sorry, my communication really wasn't good there. I'm not the only one who can review or merge here. Maybe others can also leave feedback here, including from the community.

I still maintain that I personally don't need this feature and tend to assume that it would further worsen Träwelling's performance (which is already very poor at the moment). I haven't validated this yet, but the query for the dashboard, for example, is already really... bad.

[VXGP]

All good, I understand. Regarding performance, I believe the feature is implemented in a relatively lightweight way and should not have a significant impact on overall performance.

I still hope that this feature can be merged into Traewelling, as I invested a considerable amount of time and effort into its development. If possible, perhaps another reviewer may be able to take a look at this pull request.

Feedback from others would also be very welcome and helpful. :)

[poeticpenguin]

Another friend of actually asked me a while ago, if something like that was possible. Kind of a similar situation to the Gamescom example VXGP provided. Let's just say, that some relationships cannot be dealed with otherwise.
As someone who knows what doxxing can feel, i am glad that this pull request exists - even though I personally currently (luckily!) do not need it.

Basically, it can be interpreted as a secondary "friends list" - a one-sided one; rather "non-friends".
Like in real life, where one would differentiate between buddies and friends. You might call someone a friend due to reasons, but in reality, that person should not know where your family lives for example; Only close friends.

What this should accomplish, is the opposite of "trusted users", but freely editable for every-checkin.

So far the philosophical side.

While i have no idea about the server structure, neither do i fully understand PHP code optimization yet, I do have food for thoughts:

Every user who opens the dashboard or a profile, will trigger a query, checking whether you are blacklisted for viewing specific check-ins or not. How would that exactly work?

One "showerthought" idea i had, was to only run the query, if a user has ever appeared on a blacklist. Thus, not every user will trigger that blacklist check, but only those who are already "critical". That would however mean, that a cronjob would need to mark those users reliably in a timely manner. That is not going to happen.
And in the grand scheme of things, we are dealing with private matters.

Maybe we should limit this feature to "friends" and followers for now to keep the amount of queries as low as possible. Allowing this PR for blocking any user (no matter if the person is a follower or "friend") might probably be indeed "overkill" and in the long term (not right away) cause more performance issues.

In short,
I suggest,

• Only friends and followers can be blocked from individual check-ins
• Take inspiration from the way the type box is designed and keep it as sleak/slim
• remove explanation and insert it into the insert/enter field itself
• Think, whether the "Trusted Users" feature, an existing filter, might come handy here

[VXGP]

The concept presented by @poeticpenguin is, on the whole, quite commendable. My only concern pertains to the configurability of the setting, which is currently limited to followers and "friends." What if the individual from whom you wish to conceal your check-in is not following you? Perhaps it would be more beneficial if users you follow were also included in the selection options. Also, it would be necessary for the selection on one check-in to remain, even if the user no longer follows you and you no longer follow the user, in case the user removes you as a follower.

Also, an important point is that the query doesn't only have to run if a user opens a profile or the dashboard, but also if a user who should not be able to see the check-in opens this check-in via a direct link or looks at the "En Route" section.

[SteakHarpyie59]

So, what's the status now? I think it's a really good and practical feature. Therefore I also think it's very disappointing that this feature hasn't been reviewed yet.

[VXGP]

Hello, I'll get back to you with that because no one from your end, @MrKrisKrisu and @HerrLevin, is doing it.

It is honestly impressive how you manage this "open source" project. The way you treat people who actually want to spend their own time making things better is just ridiculous. It really makes everyone feel "welcome". I wonder why Träwelling is slowly loosing users?

If you are tired of the project or just don't want to do the work anymore, why not just hand it over to someone else? There are people out there who are actually interested in moving this (at its base, pretty cool) project forward, and it would clearly be in much better hands with them. And let’s be real for a second, watching a bot do automatic dependency updates is not a big deal.

The fact that you don't even have the guts to reply says it all. I guess you finally ran out of excuses to give me. Instead of giving me at least some feedback, I am completely ignored! Yes, that makes a good open source developer!

Now others have left positive feedback, how you described would be helpful, but literally nothing from your site! If you don't need this feature, that's fine, but a developer in an open-source community project shouldn't think that way.

You can feel however you want about this, but it is a very accurate and fair point I have here. I am definitely not the only user who is tired of this situation. This is just disappointing for the Träwelling users, and you as developers are really blaming yourselves with such actions.

PS: Leave this pull request open, let's see what other users say about this Situation. ;)

[jheubuch]

Hello everyone,

I happened to stumble upon this Pull Request by chance while browsing through the Träwelling repositories, and after reading the discussion, I felt the need to share my perspective as a contributor.

To provide some context: I have been involved with the Träwelling project for several years and developed one of the open-source Android apps for the platform. Because of this, I work very closely with the Träwelling API and have a deep understanding of its inner workings. I also know most of the maintainers personally and can vouch for the fact that they are thoughtful and always act in the best interest of the project’s health and longevity.

I would like to address a few points regarding this PR:

Complexity & Performance: The visibility logic in Träwelling is already quite complex. As someone who interacts with the API daily, I share the maintainers' concerns that adding further layers of visibility would negatively impact performance. Maintaining a fast and reliable service is a priority.

User Experience: The Check-In UI is already very feature-rich; adding more toggles for every possible social niche would lead to an overloaded interface. In my opinion, the current options (public, followers-only, unlisted, private or trusted users only) already cover the essential use cases for privacy.

The Nature of Open Source: Open Source thrives on contribution, but it also relies on the maintainers' expertise to curate features and manage technical debt. A "no" to a feature request is not a personal attack or a sign of laziness - it is often a necessary decision to keep the project maintainable in the long run. These decisions should be respected.

Lastly, I have to address the tone of this conversation. The Träwelling community has always been a welcoming place, but that relies on mutual respect and our Netiquette. Personal attacks and hostile demands (like suggesting the project be handed over because a specific feature wasn't accepted) are not constructive and do not align with how we collaborate here, even if a PR is unanswered for a long time.

It is perfectly fine to disagree on a feature, but let's keep the discussion focused on the technical and conceptual ideas.

Best regards,
@jheubuch

[louboecker]

While the main technical points of why this feature might not be a great idea were already given, I want to join the discussion on the concept of the feature, which would need to outweigh the technical disadvantages of this feature heavily, since Träwelling's performance has already gotten worse over the years (which I don't blame the maintainers for, since it has also grown over the years).

I've read the gamescom example given by the author, but I don't really understand it. If there is someone you don't want to know that you are going to gamescom (because you don't want to meet with that person?), make the check-in followers only and don't have them follow you? If your relationship to that person is so bad, that you need to keep it a secret, or need this feature to lie to someone about going to gamescom, why do you need the connection on Träwelling at all? Gamescom is a big enough convention to not have to meet with that person.
I can't think of any other example where this would be needed, but to me it seems like if this feature is needed for someone, they might have to work on their communication skills.

I might have missed something, and I don't want to sound disrespectful, but I really don't get why this feature needs to be added. Happy to let myself be convinced otherwise tho.

[VXGP]

Hey @jheubuch and @louboecker, thanks for sharing your thoughts about this.

Of course I completely understand that the project is quite complex and it's not easy to add "every feature". But to be fair, at this point, why do they tell me I can build the feature in a pull request if they don't even want this feature?

I used a lot of my free time to build this feature, put effort into it, and it took a while. Obviously, it's really frustrating for me if I get ignored or the pull request doesn't get a review for several months. That's maybe also where the conversation's "tone" comes from.

I've built this feature because this was a pretty large gap in the privacy settings. Just for protocol: At the moment, you can show a check-in in Träwelling only to certain users you select (trusted users), but the exact opposite is missing – that you can hide a check-in for certain users you select, but it's still public so that other users can find it.

Another example for you, now in a positive way, @louboecker, is that you may want to surprise someone, and this person should not see the check-in, but it should still be public so that other users can interact with it. If the check-in were followers-only, people who don't follow you couldn't find it. Also, if the person you want to surprise follows you, "followers-only" would not work either.

The thing I don't understand: The feature was there, built by me, perfectly integrated into the front and backend, but still not reviewed or at least answered. I think you can understand the frustration on my side?

And let's not forget why I started building the feature. There was never a clear "No, we don't want this feature." or something similar from the Träwelling developers' side. The answer was that pull requests are always welcome. That's also why it just feels like thousands of pointless excuses the devs gave me.

Anyway, maybe I'll get a factual and detailed answer as to why the devs refuse to review my finished (now probably outdated) pull request. By the way, don't misunderstand me, I don't want to say that the devs are bad or something, but the situation is just very complicated and disappointing for me.

Regards,
Varox.

[MrKrisKrisu]

Hey @VXGP,

I owe you a direct response, and an apology for not giving you one sooner. I already mentioned in the discussion (unfortunately only indirectly) that I personally don’t want this feature, but after that I didn’t review the PR in detail or give you a clear, definitive answer. I just let the matter drop, and that was exactly the wrong thing to do. You really put in the effort and deserved a decision, not silence. Sorry.

On the feature itsel, my hesitation is twofold.

First, the social dynamic it creates makes me uncomfortable. Secretly hiding a check-in from a specific person, while it remains visible to everyone else, is a feature designed for deception: presenting a selectively false picture. I don't want to build that into Träwelling. I understand you see the use cases differently, and I'm not dismissing your reasons, but this is a line I personally don't want to cross. And to be practical about it: if you want to hide a check-in from a specific person, the tools are already there. Set it to private, followers only, or trusted users only. That covers the need without the deception angle.

Second, the technical side. Träwelling's visibility logic is already complex enough. Adding a per-person exclusion layer on top of the existing visibility system (public, followers, trusted users, private) significantly increases that complexity: in queries, in maintenance, and in the mental model users need to reason about who can see what. On top of that: Träwelling's database is approaching 100 GB, and MariaDB is not particularly efficient with the kinds of queries we already run. Things tend to look fine in local development, but I haven't actually tested this against production, and I genuinely don't know how much worse it gets at that scale. Making an already large query even larger is a risk I'm not comfortable taking right now. If you look at other social networks, none of them offer per-person hiding for individual posts either. What they do offer (Twitter Circles, Instagram Close Friends) is a trusted model, which is exactly what our "trusted users" feature already covers.

Thank you for the work you put into this.

But I would personally close this PR and not include the feature.

~Kris

[VXGP]

Hello @MrKrisKrisu,

thank you for giving me a clear and direct answer. I understand your personal ethical issues with this feature at this point. Now I also understand the technical issues with it slightly better.

It is unfortunate that the feature didn't make it into Träwelling. However, I still wish you success in developing the project!

Best regards,
Varox.