@Kalium yeah I'm imagining this as a public relations and public service announcement channel.

Positive, assuming we make sure this works how we expect.

I believe it should be fine, and I think there should be no leakage as long as accounts on broadcast.websiteleague.org never boost any posts from either side. However, I think it'd be best to test this, in order to be absolutely certain.

could, but make sure you're up for the effort involved in maintaining the denylist. the point is mainly for people on that instance to not have to maintain two accounts? (one league, one fedi). could work, but might be somewhat whiplash inducing. but being there is a choice i suppose

@artemis afaik only planned use for BWO is announcements from the @league account, so that shouldnt be a concern

@ruby oh ok i didnt realize that. makes sense to me

@artemis it would be nice and mildly funny if there was a way to simply reject all interactions besides follows and fetches from non-league instances

@walking mirage akkoma has MRF policies that can do that, i'm not sure if GTS has something similar.

No opposition from me. Sounds like a decent way to keep in touch with the League from outside. Whether that'll invite ire from the fediverse is an open question, and probably one to consider the moderation inpacts of.

this all assumes this setup won't leak content from other nodes to the fediverse - idea is a non-starter if so

@ruby i don't think there's anyway to avoid the ire of the fediverse and as such i don't think we should worry about it at all. haters gonna hate. let em die mad.

the part about leaking content from other nodes is a serious concern tho.

findings & methodology

this setup seems safe, at least if the boundary instance is running gotosocial. (i did not test akkoma, i don't think we would use it in this scenario)

I set up three gotosocial instances locally.

• 'boundary' is a blocklist-mode instance that does not specify any allowed or blocked domains.

• 'inner' is an allowlist-mode instance that specifies a single allowed domain, the 'boundary' instance's.

• 'outer' is another blocklist-mode instance.

I made a handful of posts on each of those instances to observe leaks, and i didn't find any.

specifically i tried:

• replying to 'boundary' posts from both sides

• replied to those from 'boundary' and spot checked for leakage if i searched for that reply directly. a post on 'boundary' in reply to an 'outer' post simply appears detached from 'inner'.

• on the 'boundary' account, boosting posts from both 'inner' and 'outer'. neither instance saw posts they weren't supposed to.

here's the final view of the 'boundary' account's posts from each instance at the end of my testing.

We just need to make sure all leauge instances have authorized fetch on (always is on GtS) and we aren't using json-ld signatures (which ARE transferrable, depending on how things are set up, but authorized fetch should disable them)

No objections, especially given viv's findings and that we're just using it for the @league account.

based on viv's findings, i have no objections, i'm broadly positive on the idea.

I'm also positive

@tenna iirc this is a config option, config :pleroma, :activitypub, authorized_fetch_mode: true

edit: Quick look at code suggests this option does two things:
1. Force requests to 401 when HTTP signature verification fails
2. Ensures HTTP signatures only get mapped to instances on the allowlist - fails verification otherwise (i think...)

@ruby It is, but I fear the potential of someone forgetting to set that up. I feel like maybe there’s some endpoint we could try to hit without sending a signature, and we’ll know it’s all good if it blocks the request, and it needs to be set if it doesn’t

@tenna Going off code - https://akkoma.node.org/users/:username with Accept: application/json should 401 with "Request not signed" when that flag is turned on. Tested on my own instance (with this option enabled) and it does in fact do this. I imagine we could automate this with a check against the listed admin user if we needed to

edit: Tested with a local instance that does not have this option enabled and it responds with a 200 and the user profile information. Seems like a good enough canary to me

@Tennayou may be able to GET one of the masto api calls to check. v1/instance shows a bunch of settings.

edit: or what ruby suggested!

@ruby Seems it shouldn’t be too much work, then, to put together a simple bash script that pings that endpoint for each Akkoma node. Can’t do it myself until at least later today, but I will try if someone else hasn’t done it by then ^^

@Shel Is there a practical difference, re: the trolling/"lolcow"-baiting behavior, between having the page and its posts visible (on the web) as opposed to having them syndicated (on activitypub)? I'd been under the understanding that, if people wanted to troll the public announcements around - particularly on broad fediverse, that they could have done so through links and screenshots, regardless, and the impact wouldn't differ.

@sirocyl Not really much of a difference, but I think it will be ever so slightly more convenient if syndicated and it may propagate through reposts to people who wouldn't have otherwise seen it. And with it connected to the fediverse it will exist "in their world" and they will feel a bit more proximity to us.

@Shel Right, that's a thing to keep in mind, too. Broadcast might have to be involved in blocking instances known for abuse, too, and taking on other instance-level moderation. Someone ghost-replying to our posts, or posting shock material in replies, is a definite risk if those avenues are open.

pending the resolution of this point raised by Kalium my vote is an abstain (was an approve). i still have no strong priors here one way or the other on how this should be done since it's not my wheelhouse, but if this causes less problems for us than how we're proposing to go about it currently we should probably take it

A possible case for this, is that broadcast.wlorg can reach, and be reached by, instance admins who may have an account on the broader fediverse e.g., for technical alerts or other cases where an instance-owner's home instance may be unreachable or broken.

there's still about a day to go on this, but i think it's evident the initial plan here is probably not workable (most immediately: we're still short of quorum by a bit and there are two outright objections); additionally, some considerations mentioned by @shelraphen upthread that would apply to even @kalium's scaled back idea have been raised that we might want to address. so i'm not sure on what the best way forward is.

in the short term, if nothing else, it seems like Broadcast would make a good channel for league-wide updates and announcements?―i'm not totally clear on if we already intended for it to be that regardless of being the sole node federating outwards.

I think something that would be very useful inside of the league is if there was an account that broadcasted when new nodes are added, and tagged them. Then we could all see those messages in our clients and click through them to both test federation & optionally follow the new admin to start getting some posts flowing.

I'm not sure if we'd want to avoid doing that with a node that is also publishing to the broader fediverse. maybe.

after hearing everyone's objections and arguments i no longer support my own idea. we can spin up another GTS instance if it's merited down the road