I agree

so not configurable by a third party ( the provider of the permission set)

I agree, but I think the permission set icon's in the consent screen should be provided by the PDS ( the one you trust with youre data) and should be an indication of the risk you take agreeing with a certain permission set, possibly provided by some configureable policies on the PDS...

It would, but you have the same problem if the domain name in your did expires. plc mirrors already solve this, just configure multiple mirrors in the did resolver

I am locally using a ( virtual) plc directory which is a proxy to multiple plc directories

Personally i'am against"polluting" the plc did with an domain name the did:plc not containing a domain name is its strongest characteristic if you ask me. Create the solution outside the persistent id...

PPS ( Personal Processing Server )

Thank you @ngerakines.me for fixing lexicon validation in @lexicon.garden

I'am planning a lot ( Farm data related ) but most of it is waiting for reaching consensus in the community about how permissioned data is handled. For the near future i was thinking about a generic geometry index ( index with backlinks to records containing a geometry type )

just create an atgeo format dealing with this for openlayers and leaflet and you have most browser based geo covered

picking the correct defaults in the lexicons would simplify things a lot, in this lexicon the default coordRefSys is EPSG:4326 ( lat long ) so could be omitted and if you choose a default float64exp value of -6 lat 52.156160 lon 5.387638 would be written as 52156160 5387638

It's not about projections used in the geometries but about how to represent a float, ignore the projection. But for serious geo data you eventually need projections

at://willem.dobs.nl/org.custorium.temp.jsonfg.testRecord/3me6siayjo42k

and a record using this lexicon here pdsls.dev/at://did:plc... then with some tooling you could create the floats on the fly

at://willem.dobs.nl/com.atproto.lexicon.schema/org.custorium.temp.jsonfg.geometryObject

Another way without changing the base atproto data model is introduce a float64 and float64exp lexicon definition somewhere in the com.atproto.lexicon namespace as used in this lexicon pdsls.dev/at://did:plc... ...

true, but it's not something we should pursue I think

want, because you want to be able to use an app without installing lexicons first. A PDS can still use local versions of a lexicon which does override the dns lookup.

Not really, the lexicon nsid ( reversed DNS id ) is used to resolve (dns lookup) the PDS where the lexicon's are hosted ( discovery ). This is needed if you want a PDS to be able to do basic lexicon validation, otherwise a lexicon has to be deployed at every PDS using it, something you don't..

The party who defined a service interface (lexicon) differs from who implements it ( endpoint). I personally would like to reserve the com.atproto.* namespace for generic protocol level definitions ( domain agnostic ), feed is more a concept from a social app domain ( something build on atproto )

like ( did:plc), lets just thust each other,and related see also bsky.app/profile/burr...

Renaming / moving is not a solution, at least not for interoperability just use whats already there and add extra's you want in "sidecar" records, thrust the lexicon characteristic that its backwards compatible, maybe implement transparency logs to be sure ..

solving this in a usable way would remove a lot of protocol concerns (handle also) but i think what we have is the best you can get for now.

My PDS implementation does work with sifa.id, so my guess it's something in your'e PDS and like @gui.do my guess is that it is something DPop related (signing alg negotiation ? )

Shelf & binder

if all my wishes would come true that fast...

@dholms.at I guess it's almost time for another entry in you're diary ? 🤔

My vote goes to the alternative and in my opinion cleaner approach , "always specify a full service did in the aud field", I guess the serious (read actively maintained) atproto services and clients will implement this. Changes are needed either way

When the bsky app starts using OAuth it will be redirected to bsky.social ( or the IDP of your'e PDS provider) to login. So if you have a session active it will be reused when you login with another app using OAuth

I run into it frequently, will be fixed when the bluesky app OAuth2 support lands

On a Rpi with 500GB ssd at home

Backfill duration was +/- 26h