A2. Co-deploy Ory Hydra + its DB; configure opaque tokens, DCR, PKCE-required, refresh rotation, revocation, and TTLs (~1h / ~30d).
Can you dig into it and explain what exact implemented by this lib vs what need to add around it?
25 Matching Annotations
- Last 7 days
-
laughing-bassoon-7p6pm2g.pages.github.io laughing-bassoon-7p6pm2g.pages.github.io
-
-
Ory Hydra
this is GO library, need to use oidc-provider library
-
Implementation
What missing for me is when and how to get the apikey of the account, and how allow choosing which apikey to use? Maybe we need to add step to the consent page to show all account's apikey and allow user to choose which one to use.
-
redirect back with code
What the purpose of this step, why not sending the secret in this step?
-
Feature toggles
I think feature flag not relevant at all in this flow. Because 1. The flow started before user is identify so no context exists. 2. It's a totally new flow, so no backward compatibility needed
-
Consent screen
How this screen is display? Client should identify the user came from MCP context and redirect it after the login process is ended successfully
-
make the issued token something the platform already trusts and that we can revoke in a single call — instead of a signed token that would need new signing infrastructure.
Need to make sure Kong identified it as apikey for manage the rate limit of the account.
-
Revoke = delete the credentialOne Admin-SDK call kills a connection — no blocklist, no waiting for a signature to expire.
Where this option is located?
-
What stays identical: the proxy still forwards ?apikey=; Kong still validates a key with the same plugin; api.tomorrow.io is untouched; existing x-api-key callers (server-to-server, n8n) keep working unchanged.
Does it return the existing API key to Claude? You should provide another secret key. It's not clear to me who converts this key to the API key.
-
-
laughing-bassoon-7p6pm2g.pages.github.io laughing-bassoon-7p6pm2g.pages.github.io
-
Today
test2
-
Slack OAuth + token storage — slack-sender-service settles delivery, but the per-account "Connect Slack" install + token store is still net-new (and the service must be extended to resolve a token per account). Where do tokens live & who builds the install flow?
Im not sure we want to do it as part of this task.
-
so customer Slack routes through slack-sender-service instead.
maybe need to call to slack from notification-service, in order to keep all things in one place. and user slack-sender-service as a provider
-
dispatch audit
i cant find another place to raise my thought about the audit: I think we need to change it to log what exact sent, show alert as row and drill down of users and channels (maybe adding status from providers). today it very hard to read it and not connect to mute channels / scheduler etc... It not part of this effort of course but I want to think like that when we build the system.
-
02 · CONTENT (render-context)Notification content arrives as a dynamic key/value object the realtime alert computed at trigger time — point-in-time-correct, no content fetch. Enrichment shrinks to recipient resolution (03) plus a rare fallback lookup via references[].
I didn't understand what was meant here.
-
alert engine — FF routes old vs new
Why need this FF, we decided the new distribution connect to the new engine only, no?
-
- Jul 2026
-
laughing-bassoon-7p6pm2g.pages.github.io laughing-bassoon-7p6pm2g.pages.github.io
-
User wants to know which assets are at risk.
I think it must have, and risk is what assets are triggered right now - read from monitors-events like locations do.
-
User wants weather at an asset's destination.
Do you have a scenario in mind? But in any case it sounds like something Gale can do without any specific flow/prompt based on user question.
We should be careful about implementing specifoc cases that are not generic.
-
on all his assets
I think this use case is not realistic and we no need to support it. we can do something similar to "Your location" questions and get the top 3-5 triggered locations and summrize them.
-
-
laughing-bassoon-7p6pm2g.pages.github.io laughing-bassoon-7p6pm2g.pages.github.io
-
Populate the fixed name field (from attributes.event) and derive a color from severity, both in the SWE transformer. These are data-completeness/enrichment concerns valid for all consumers. Severity does not need a dedicated semantic type for v1.
We dont need to change the transformer, please ask data team to fill all missing fields
-
Product / product surfaces (default + per-account)
Let's start with all attributes in this phase, and ask product/design if need to add this capability
-
primaryAttributes
This param control on assets page columns, I think need another one for side-panel/bottom-sheet view.
-
Derived display valuesderive a color from severityETL transformer (as a typed color attribute)Data team / all consumers Feed-intrinsic map stylingpolygon color/icon by attribute valuefeed-configuration-api ViewData team / any map renderer
Colors should move to display configuration - but let's do it as part of the display conf task
-
severity→text, timestamps→text
- start+end are strings but in the standard format.
- severity - need to ask Chen to set it outside the attributes with a generic value to be align to all feeds.
-
- Jun 2026
-
laughing-bassoon-7p6pm2g.pages.github.io laughing-bassoon-7p6pm2g.pages.github.io
-
The backend sets it on every source it sends
the client is not calling to vector tile directly? how the backend will add it in the middle?
-
views-vm-api
Is it not better to place it under overview-vm? In my understanding, it's totally connected (like monitors-events and insights dashboards in the platform). Having a dedicated service for viewing only seems wasteful to me
-