@Canageek@chr in theory, makes it easier to create spam accounts and bypass other restrictions on account creation I guess? in practice I don't know if it was ever really a problem, I thought stack overflow mentioned it when they removed openid support but seems like I was mistaken, they were mainly concerned about maintainability and how complicated it was: https://meta.stackexchange.com/questions/307647/support-for-openid-ended-on-july-25-2018
@chr part of the problem is that they're technically correct, which is why it's important for us to talk about open-world web systems as well (I don't know a good name for this, but see e.g. IRC as a good example of the opposite)
@cwebber maybe? I mean, if someone sends me a link to a private toot, I probably *want* to make sure it's in my history, etc. I don't know if there's a one size fits all policy here.
@cwebber hmm I'm kind of confused—if we don't care about browsers, why not just put the capability in the URL directly? web server logs? just having nicer semantics?
thinking about Federated Learning and what "idle, plugged in, and on a free wireless connection" might mean as a source of unintentional bias in the dataset.
@emacsen ah, that's interesting, I hadn't gotten to that section. That seems like a big deviation from "standard" activitypub and i'm not sure that it's going to be effective in practice (it creates a lot of busywork for both delivering and receiving servers in exchange for a very marginal benefit in the case where a message is rejected). but it's a really interesting idea!
@emacsen I think there's a small modification of this that recommends a "postback" Reject activity to the actor's inbox when an activity is rejected, but that also has downsides, such as DDOS amplification.
@emacsen one note about the "Bounce Messages" thing is that nearly many activitypub implementations process activities asynchronously in some sort of job queue, so it's impractical to expect them to be able to provide a synchronous error message (which is why mastodon uses 202 Accepted as our status code when processing activities)
@emacsen i agree that this is kind of confusing language when combined with the MUST above, but i believe it's still consistent when both requirements are read together.
@emacsen ah, i don't think any current implementations work the way you're describing. (where forwarding the reply bypasses checks the recipient might do). The AP spec explicitly says "The server MAY filter its delivery targets according to implementation-specific rules (for example, spam filtering)." (which means it may choose not to forward replies that it considers spam)
@emacsen what value does transferability have in an anti-spam system? isn't that just strictly worse then blocking individual actors? (if each actor can get its own inbox, which ties into my comments on the "pet names" proposal)
@emacsen A couple of your proposals seem like they would limit too much—the pet names proposal seems to boil down to "don't allow replies from people who don't follow or aren't followed by people you follow or are followed by", which seems like it would basically get rid of the local and federated timelines and any interaction on those timelines.
(.... although, now my brain is thinking like, "well, we could probably set the rabbitcast up in the afternoon, and then just started it when you happened to be around, then you would just be deriving incidental benefit from something we would have done anyway, like if your roommates are watching TV")
@ninja@fribbledom the only requirement for hosting ActivityPub authoritatively on a domain is serving a single static file, so while it's technically *slightly* more tricky to set up, I think ActivityPub completely supports this. you just need server software that is willing to allow you to use custom domains. (which to my knowledge nobody has implemented yet)