tl;dr non-AtprotoPersonalDataServer services might host records, let’s introduce following AT-URI syntax with optional service field to reference those non-PDS hosted data. at://tangled_knot@did:plc:user/... ^^^^^^^^^^^^ ^^^ | path can be any format | (NSID/rkey prefered, but not enforced) service name (default to "atproto_pds" when omited) In this proposal, I’m going to explain why we need cross-service reco...
Bringing back at://
I’d also like to voice a strong dissenting opinion: a separate URI scheme follows long-standing precedent, reduces cognitive overhead and software complexity by making the transport distinction explicit, and has less ambiguous error handling. I think this direction trades short-term convenience for long-term ambiguity. The transport models are incompatible, not variants of each other Public atproto records flow through a well-understood pipeline: repos export as CAR files, relays consume fireh...
proposal: ingest repo records #282
`sh.tangled.repo` records are one of the last few records that need atprotation (2-way sync between appview/pds). this one is tricky because we want consistency between knot state, appview state and PDS state. the path forward is described below: - migration to did/rkey syntax universally: in several places, we utilize `did/repo-name` as a globally unique identifier for a repository, we should migrate this to `did/rkey`: * for the tangled appview: this means reworking our ACLs, routers and DB to use `did/rkey` or ATURI as a globally unique identifier for a repo * for knots: this means changing paths on disk to be `did/rkey`, allowing git ops to `host:did/rkey` , updating ACLs, and XRPC endpoints * for spindles: this means updating ACLs and XRPC endpoints - once this is done, we can define ingestion logic for all services in the network to pull sh.tangled.repo records * for the tangled appview, this should create/delete/update a repo pointer record * for knots: this should create-or-ignore/delete-or-ignore/update-or-ignore a repo on disk. migration of repos needs to be thought out here. * for spindles: as above - define edge-case behaviors: * when referring to repos by rkey, it is possible for clever users to create duplicate records with the same repo-name, appview routers must handle this ambiguity with a new interstitial page that offers a redirect, knots must return an error upon push/pull on ambiguous git URLs * the `knot` cli can introduce a command `backfill` or `sync` to bring knot state up to sync with the rest of the world (repos, collaborators, pubkeys, ACLs etc.).
tassis/atfield-core
Framework-agnostic AT Protocol utilities for identity resolution and public record reads.
Connecting records, web pages and apps
This is a bit of a follow-up to Mapping web pages to canonical AT records We’re continuing to work on making the Bluesky app more Atmospheric, building on features like the Germ, Streamplace, and Standard Site integrations. This leads to some common questions that have cropped up before, like: what’s the best way to link an atproto record and a web page, and how does it know which app someone is using? This is relevant to a few proposals and other conversations and I want to try to tie them tog...
Introducing plcbundle - Tree For You
A Transparent and Verifiable Way to Sync the AT Protocol's PLC Directory
@tynanpurdy.com asked for this feature and I like it: every atproto app should support AT-URIs as top level routes, @pds.ls-style. Makes it super easy to integrate. So this would be an argument for e.g.: `https://bsky.app/at://did:plc:rbvrr34edl5ddpuwcubjiost/app.bsky.feed.post/3micfxauzu22c`
Support top-level AT-URI resolution · Issue #1012 · streamplace/streamplace
github.comI wrote my first #atproto community discourse topic. Pretty simple idea, but can be a good groundwork for private data, group-owned data or off-protocol data.
[Proposal] AT-URI for cross-service records
discourse.atprotocol.communityIs there interest in an ATProto service that given any URL, returns a unified backlink summary across the ecosystem? E.g., bookmarks on @semble.so , mentions on Bluesky or @standard.site , annotations in @margin.at, etc.
@dholms.at thinking about permissiones data. What if: Permissioned data URI was at://<PDS did>/<record type>/<rkey> exactly the same as public data. The PDS would handle the space assignment opaquely and do a 4xx response with some space aturis. Client goes and grabs a space cred and retries
I recently got super into the ATProto spec and how different services use PDS to store the data, I put together a quick client-only website that presents all those records in a single, consolidated feed of all my activity: at.diego.codes
at.diego.codes — Diego Vicente
at.diego.codesSharing this! Wish I'm not late for #IETF126 Tangled found PDS doesn't fit well for contributions even with upcoming permissioned space spec. So, we are planning to store record-like data outside of PDS, in Knot. This is a post explaining the reasons & upstream spec change we need. #atproto #atdev
tangled-cob.md · by boltless.me
tangled.org
