Transparency #200

New Issue

brian · 2020-11-01T06:50:17+01:00

brian commented

2020-11-01 06:50:17 +01:00

FediBlock.org currently lacks any form of transparency or guidelines. I do not believe a list like this should be administered by one "anonymous" person, which is how it seems to be run right now. The FediBlock.org homepage currently contains no indication of who is running the site.

Decisions like this should be made by a council of people with a clear rubrik of what does and doesn't belong on the list.

FediBlock.org currently lacks any form of transparency or guidelines. I do not believe a list like this should be administered by one "anonymous" person, which is how it seems to be run right now. The FediBlock.org homepage currently contains no indication of who is running the site. Decisions like this should be made by a council of people with a clear rubrik of what does and doesn't belong on the list.

tanduu commented

2020-11-01 11:11:36 +01:00

Yeah, i agree we should do that. Altough the project is not run by one single person, rather a kind of collective of 3 people.

However, i also think that actual content is more important compared to who exactly runs this instance. But that may be naive.

Yeah, i agree we should do that. Altough the project is not run by one single person, rather a kind of collective of 3 people. However, i also think that actual content is more important compared to who exactly runs this instance. But that may be naive.

brian commented

2020-11-01 11:33:15 +01:00

For a trust-based project like a blocklist, I think it'd be better to have that in the open (even if it's just fedi handles / not irl identities).

Relevant conversations should probably also be public. I see that this server also runs Prosody. One possibility might be to create a MUC for this purpose and publish it with mod_http_muc_log.

For a trust-based project like a blocklist, I think it'd be better to have that in the open (even if it's just fedi handles / not irl identities). Relevant conversations should probably also be public. I see that this server also runs Prosody. One possibility might be to create a MUC for this purpose and publish it with mod_http_muc_log.

tastytea commented

2020-11-01 12:04:03 +01:00

The idea is that trust isn't necessary because all claims are verifiable (and should be verified before blocking, in my opinion).

Relevant conversations should probably also be public.

I agree, they should take place in the Pull Requests and Issues in this this repo, in my opinion. That's easier to look up than a chat log.

Decisions like this should be made by a council of people with a clear rubrik of what does and doesn’t belong on the list.

Yes, that should be made clearer.

The idea is that trust isn't necessary because all claims are verifiable (and should be verified before blocking, in my opinion). > Relevant conversations should probably also be public. I agree, they should take place in the Pull Requests and Issues in this this repo, in my opinion. That's easier to look up than a chat log. > Decisions like this should be made by a council of people with a clear rubrik of what does and doesn’t belong on the list. Yes, that should be made clearer.

tastytea referenced this issue from a commit

2021-01-23 02:35:09 +01:00

[WIP] More transparency.

This repo is archived. You cannot comment on issues.