how can detect new labeler joining to the network?

[itaru2622]

related to #2511, #2552, bluesky-social/social-app#3377

I'm looking for the way to detect new labelers joining the network, as soon as possible,
any idea?

[itaru2622]

I found a way with heavy overhead, like below.

get all account info from PLC with /export API in some interval and take their diff.

more smart way wanted.

[bnewbold]

The recommended way is to monitor the firehose for labeler declarations, and then resolve the DID from there.

The trick you mentioned of enumerating all DID PLC identities and looking for labeler service declarations also works for finding pre-existing labeling services... though technically there could be did:web labeler identities (which we recommend against).

[itaru2622]

@bnewbold thank you for response.

I know that com.atproto.sync.subscribeRepos can get events in firehose when some changes happened on repo.

but the most of events on subscribeRepo would be related to posts i.e noises to find labelers.
as the result, from the point of view of ratio on signal vs noise, it is not smart way, unfortunately.

If subscribeRepos supports conditional subscription (besides cursor), then it would be the best choice.

[bnewbold]

It is very low signal to noise, but for now it isn't that big of a deal: computers are fast, and generally inbound bandwidth is free so this only costs the Relay compute resources.

Building out a more complex relay that can do filtering, queries, or other functionality is something that has been discussed a lot, and may be more important in the future when the overall event volume grows, but for now we recommend folks just subscribe to the full firehose and filter locally.

[itaru2622]

@bnewbold I try to use subscribeRepo to detect labeler joining and its service endpoint.

• Is there any good debuging tool for subscribeRepos which can decode messages?
• could you describe more detail how to find ozone service DID and its service endpoint (URL of ozone) from events received subscribeRepos? because of too low signal-to-noise ratio, it is hard work to find meaningful message without hints.

[itaru2622]

I finally made test tool for finding ozone DID from subscribeRepos, and got serviceEndpoint from its didDoc.

but my tool couldn't find any while running hours. it figures out labeler joining is too rare cases...

# there are two types of events regarding label definition in subscribeRepos stream: creation and update.
# case 1) creation of label definition
{
  '$type': 'com.atproto.sync.subscribeRepos#commit',
  ops: [
    {
      path: 'app.bsky.labeler.service/self', // <= regarding labeler
      action: 'create',
      cid: CID(bafyreiesy2ybq4booyf5ztkwjqvijrklc7qyuu3kps7xqqcu26cxxxxo4m)
    }
  ],
  rev: '3kvb5iscdu22d',
  seq: 7,
  prev: null,
  repo: 'did:plc:...pil66p4dqiqe5bu3pjtg', // <= DID of labeler, lookup didDoc and find serviceEndpoint
  time: '2024-06-19T07:08:29.032Z',
  blobs: [],
  since: '3kvb4wcy35s2d',
  blocks: <Buffer 3a a2 65 72 ,...>,
  commit: CID(bafyreihz5nw7s2phvtye3kehwcdj6ta7iogfkf6fefx6oeisgdjqkopfca),
  rebase: false,
  tooBig: false
}

# case 2) update (and delete) of label definition
{
  '$type': 'com.atproto.sync.subscribeRepos#commit',
  ops: [
    {
      path: 'app.bsky.labeler.service/self', // <= regarding labeler
      action: 'update',
      cid: CID(bafyreic3svjuk42wccjztvxv3s7lxb5pdjydvermpm5znk2ndiq7v2wxr4)
    }
  ],
  rev: '3kvb5ljfuzk2d',
  seq: 8,
  prev: null,
  repo: 'did:plc:...pil66p4dqiqe5bu3pjtg', // <= DID of labeler.
  time: '2024-06-19T07:10:00.272Z',
  blobs: [],
  since: '3kvb5iscdu22d',
  blocks: <Buffer 3a a2 65 72 6f ,...>,
  commit: CID(bafyreibecowthjjmz3xs4nc4vqvdi4ylnmv2qpypasm5stzhcshdtesbmi),
  rebase: false,
  tooBig: false
}