On a technical POV, I think that we could support both behaviors by allowing the oauth-provider to be configured to use a particular (set of) collection & data mapping function so that actors with their own deployment of the Bsky PDS distro can customize where they get profile data from.
For "hosting only" PDS's (like Eurosky), this offers a great way to differentiate from other offerings (like "app tied PDSs"): allow users to update all their profiles from all their services from a centralized location (the PDS account mgt UI), by updating multiple records at once.
I am definitely not opposed to the idea. But I also see this as a way for PDS providers to differentiate from each other. For example; for PDS's tied to apps (Tangled, Spark, Blacksky, Bluesky), I makes more sense from a UX pov to use the app's namespace as profile data.
They are probably built on atproto...
<pds-url>/account
Should be fixed.
Hey y'all, I just released a new version of the PDS distribution that fixes that hCaptcha/COEP issue. Update to v0.4.219 and get the new account manager interface as added bonus.
I'm personally open to both. They would both be "internal" features that don't require spec changes.
The hcaptcha alternative might be harder to implement correctly though...
It does. And thank you.
This is what I came up with too but I gotta admit it does sound a little weird... Like "Mon compte atmosphérique" makes more sense strictly speaking but then it sounds like it's referring to something different, which we don't want.
"pseudo Internet" then ?
Yeah, that's why I'm asking...
Yeah that makes sense
Screen shot of the PDS account manager interface, giving some context of where the "My Atmosphere Account" would show up
sneak peek
Noooo !
So @signez.fr , how would you translate "Atmosphere account" in french ?
Is my understanding correct that you loose ordering when processing a stream with multiple workers? In other words can you do:
Async stream > parallel processing of items (with high watermark to keep memory in check if one task is very demanding) > async stream (with same ordering as input)
This looks pretty neat!
This lead me to open 3 different issues, not counting our internal bug tracker 😅
bugzilla.mozilla.org/show_bug.cgi...
github.com/hCaptcha/rea...
github.com/hCaptcha/rea...
Turns out this is Firefox complaining about the fact that it, itself, replaced the iframe src to display an internal error page. This was a bit misleading...
I reported it here. Let's see what happens. I'll check with the team whether we want to allow disabling COEP headers in the meantime.
github.com/hCaptcha/rea...
Chrome gives more insightful details. Looks like hcaptcha stopped sending COEP headers.
I also see a CSP error but the `frame-src` directive does match what hCaptcha expects:
docs.hcaptcha.com#content-secu...
1) If I use "Firefox for Android" hCaptcha shows up
2) If I use "Firefox Nightly", I get a COEP error, which gets truncated by the hCaptcha lib. Manually editing the iframe's height reveals the problem:
Is this recent or has it always been the case ?
pie(zza) thought
I'd be fine with considering a particular cid a resource if the PDS indeed maintained a list of versions. But the protocol does not really prescribes that. A query string would be more akin to an etag/ifmatch
Well the hash fragment is already used and must be a json pointer within the record. Also, hash fragment are typically not sent as part of the request (in http at least), whereas here, we do want the vid to be part of the request (kind of like etag works)
Semantically, I personally feel that a query param (<at-uri>?cid=<cid>) would be better suited to describe a record at a particular version, rather than a sub path. First because the version is not really a sub resource of the record. Second because this locks this syntax for any future use.
I'd rather allow { type: string, format: at-uri } to allow format specific options than introducing a new type. First because it will lead to better compatibility. Second because it paves a better future if other format also need specific options (e.g dates beyond year 9999, cid version, etc.)
"watsm"?