Btw I am not sure if the other companies involved are listed on the publicly listed pages or internal one, would be good idea to check it again. All I checked was https://github.com/ojcp-org/ojcp/blob/main/GOVERNANCE.md

https://github.com/ojcp-org/ojcp/discussions

Tangentially on a personal note I find it offensive to use the word protocol when proposing a solution in the beginning at this early stage. My reservations extend all the way to MCP as well, glueing things together to make it work for your own use case isn't a worthy candidate to be a protocol. There is no mention of any committee members other than Recruitics which makes it hard to capture all the use cases, concerns, long term vision from different parties.

On second question of why the tailscale developers did it, its possibly for the same reason why they invested this much into debugging this issue. Some one believed the current behavior did not fit into their architecture, they want to be more performant and take control over things. A big part of me considers this is a required exercise to try, grow and learn. The only thing they could have for improvement would be to have these old hands on architect kind of folks on their team who might have hinted/pointed them to the problem a long before. Challenge/chances are that these older folks would have even stopped them from going in this direction in the design phase itself.

> running boring technology in a non-standard way is a risk.

It was a good read and reminder that the industry is loosing experts gradually. I am not a DBA and yet I have heard about this behavior at least couple times in the past as something to avoid. Its just one of those things which didnt get a chance to be documented cause experts avoided it and regulars didn't get into

The compliance rules at times are outdated and people skirt around them by following the worded rule instead of the intent.

1. The down side is that it cannot be used across the clients even for the same user

2. Using the same encryption key was a bad choice here, a per user key would have solved this issue for sure.

The flaw is that the data is not strictly tied to user session, making the session data hijacking a lot easier.

1. Its a security issue.

2. Publicly available sessions make it much worse

1. Managers were asked to provide mid year rating for their reports, this is not something that happens otherwise

2. Managers were asked to mark the reports which are not regrettable attrition

3. The biggest downside of all this is that it makes people to invest a lot more efforts on being in managers good list instead of focusing on doing a good job

1. Who are you saying NO to - Ideally what you are saying NO to should have mattered more however in real world incentives and repercussions matter a lot

2. How are you saying NO - Even if one saying a direct NO the tone matters, other times there are ways where you can add precursor conditions (which make it a automatic NO) or you put it on the backlog way too far down that it never gets a real chance to be acted upon.

Putting it on the backlog is the corporate style of saying no without saying NO. Smart people just avoid getting into backlog and just truncate it if its been in the backlog for way too long.

You are just spending some more disk space to avoid synchronization issues. Denormalization for performance is a really common pattern, just that people do not start with it in the first place itself

1. Backgrounds process can back up

2. They need context of the user and need to switch context per user

3. What if they fail, you create some DLQ or another process to handle the failure

4. Who looks on those failure and how do they act

TLDR; there is always a cost

Unfortunately you cant have it both ways which makes it hard problem to solve for everyone

From what I understand the pressure has created even Google to be a lot more aggressive than what it was before. Not entirely sure but I believe google has two categories of scrapers, the regular one and a new one for AI