Post Ab5rMJJcSTcoHTxKgi by db0@hachyderm.io
(DIR) More posts by db0@hachyderm.io
(DIR) Post #Ab5WQFCrZyPferpXjU by pixel@desu.social
2023-10-24T07:27:07Z
0 likes, 0 repeats
what if someone made a blocklist page that automatically puts out announcements for new entries, but does the same for updated/resolved entries, so instance administration can restore/re-enable federation again instead of forgetting about doing so?Top tier use case for our federated protocol.
(DIR) Post #Ab5bXqueHoU8Oql3HE by db0@hachyderm.io
2023-10-24T08:24:30Z
0 likes, 0 repeats
@pixel The fediseer already does something like this https://gui.fediseer.com/action-log/log. Also available via REST API so one can ingest it automatically.
(DIR) Post #Ab5epitd868Yc1UiYq by pixel@desu.social
2023-10-24T09:01:21Z
0 likes, 0 repeats
@db0 that's a start, but having the action log distribute via AP would be an improvement that doesn't require staff to always check that page.
(DIR) Post #Ab5f1TwgXejvibWx28 by db0@hachyderm.io
2023-10-24T09:03:27Z
0 likes, 0 repeats
@pixel So far I know, there's no shared distributed allowlist/blocklist via AP either. People doing shared blocklists are handling it via manually retrieving it from various sites they trust.
(DIR) Post #Ab5pNNNIeRi5Fh3eE4 by pixel@desu.social
2023-10-24T10:59:29Z
0 likes, 0 repeats
@db0 well, this is not about the actual blocklists being shared, but rather just announcements/adjustments to blocklistsso as an admin I wouldn't need to constantly recheck my source, but rather get a post about a specific instance having their block recommendation lifted or so, as an example
(DIR) Post #Ab5rMJJcSTcoHTxKgi by db0@hachyderm.io
2023-10-24T11:21:38Z
0 likes, 0 repeats
@pixel Sure, but that implies shared blocklists. I.e. there's no need to announce changes to blocklists unless there's an expectation of shared blocklists.
(DIR) Post #Ab5rVbTSJXk5CmzJzM by pixel@desu.social
2023-10-24T11:23:23Z
0 likes, 0 repeats
@db0 ah okay, now I get you