Operations
Dids
Last Operation
Operations & Dids History
Loading...
PLC Uses (approx The data processing for this graph is quite intense, so a bunch of
optimisations are applied which makes the numbers on this specific chart
drift over time. The same code that watches the PLC for changes, also
serves the API and keeps a copy of the computed data in memory, but
because a did:plc's pds/service can change over time a did may get
counted twice since it doesn't know how to decrement without a costly
check. The data is peridoically refreshed from the database to help
mitiage this. If you have any better ideas of how to do this, let us know.
)
The data processing for this graph is quite intense, so a bunch of optimisations are applied which makes the numbers on this specific chart drift over time. The same code that watches the PLC for changes, also serves the API and keeps a copy of the computed data in memory, but because a did:plc's pds/service can change over time a did may get counted twice since it doesn't know how to decrement without a costly check. The data is peridoically refreshed from the database to help mitiage this. If you have any better ideas of how to do this, let us know.
Loading...
PDS Claims (approx The data processing for this graph is quite intense, so a bunch of
optimisations are applied which makes the numbers on this specific chart
drift over time. The same code that watches the PLC for changes, also
serves the API and keeps a copy of the computed data in memory, but
because a did:plc's pds/service can change over time a did may get
counted twice since it doesn't know how to decrement without a costly
check. The data is peridoically refreshed from the database to help
mitiage this. If you have any better ideas of how to do this, let us know.
)
The data processing for this graph is quite intense, so a bunch of optimisations are applied which makes the numbers on this specific chart drift over time. The same code that watches the PLC for changes, also serves the API and keeps a copy of the computed data in memory, but because a did:plc's pds/service can change over time a did may get counted twice since it doesn't know how to decrement without a costly check. The data is peridoically refreshed from the database to help mitiage this. If you have any better ideas of how to do this, let us know.
This graph shows what did:plc's are claiming is
their PDS. Invalid PDS' are ones that are clear spam (such as
non http/https urls or private addresses), non-pds services such
as a Tangled Knot, or hosts that didn't respond correctly (or at
all) to a com.atproto.server.describeServer xrpc request. If a PDS is marked as Valid, that doesn't mean they
have exactly the users they say they do, someone could still claim
to belong to a PDS when in reality they don't.
Hosts are periodically re-checked to ensure that we don't mark something
that was just temporarily offline as invalid. Unless it's clear spam,
we assume a host is valid until the worker gets to checking it. If
something is showing up as valid that you believe isn't (or vice-versa),
hopefully it's just behind schedule but you can always file an issue to be sure.
Loading...