Подтвердите e-mail

Для публикаций, комментариев, реакций и сообщений подтвердите адрес.

←

Публикация

Andrew Lisowski 💻

I realized I was being stupid and that all labelers should just be supported 😅 I filtered out all the dead ones ~60%

Standard Reader

Labelers v2 in Standard Reader: we deleted our own labelers. Any atproto labeler now works with zero setup, and your installed Bluesky labelers follow you to our app! The directory is the whole network, ones we think are for @standard.site near the top.

Обсуждение

1 прямых ответов · 7 сообщений

JP

Perhaps a stupid question (I’ve not looked into labellers much yet); for the labellers that label records (rather than accounts), do the ones that exist today often tag non-Bsky records? (Ie. do they label site.standard.document records, or any other records with text fields?)

Ответ для JP
Andrew Lisowski 💻

They dont but they can i'm pretty sure. The 1 labeler i had doing it was pretty bad (ai writing) so thought it would be better to make it easy for existing labelers to integrate

Ответ для Andrew Lisowski 💻
Andrew Lisowski 💻

I kinda think @standard.site itself should define labelers if we do. IMO it kinda feels better for this to be shared infra though

Ответ для Andrew Lisowski 💻
Andrew Lisowski 💻

Also most the labels were account labels so why not

Ответ для Andrew Lisowski 💻
JP

That makes perfect sense — plus with tools like standard reader doing this there’s more incentive to run labellers which span lexicons 😊

Ответ для Andrew Lisowski 💻
Emelia

Whilst they can, current labeler service declaration records are within the bluesky lexicon, not the atproto lexicon, the same problem as feed generators. If these are meant to be protocol primitives, then we should lift them up and advertise inputs and outputs.

Ответ для Emelia
JP

I think they’re very useful as protocol primitives! I’ll check and/or bring this up in the atproto discussion forum 😊