Yeah you are absolutely right. Going from receiving a few hundred/thousand upvotes on average to a handful of votes probably doesn’t feel good.

I kinda wonder if it goes hand in hand with people wanting voting and for the voting to mean something. I think they are not happy when they post and don't get a few thousand upvotes or something.

Part of me thinks that maybe these people just expect that since most major websites have been owned by companies which are beholden to growth, they expect the fediverse to be beholden to that same growth. But the fediverse is not owned by a single entity, and does not need to make a profit to exist. It does not need to grow to survive, and its infrastructure means that it probably could not handle exponentially more users in a short time.

I have not expressed it before but I basically agree. If the fediverse grows fine but im good with what it is as it is.

The kinda people who think this place is dead are exactly the kind of people I am glad aren’t here. They value quantity of content above anything else. They don't care about community. They don’t even care about quality. All they want is a website that gets posted to at such an obscene rate that they never see “old” posts.

@rwg dead for whom...

I don't think they close it on Brooke Vibber Day on purpose. I was just reading the Brooke Vibber Day Wikipedia page.en.wikipedia.org/wiki/Wikipedi

@evan@cosocial.ca what's the group, a group of users? 😅

@activitypub This is an experimental group server I built using activitypub-bot. It is very simple. It's made to implement the work of the Groups Task Force at the Social CG: github.com/swicg/groups

@evan@cosocial.ca cool is an understatement! These researchers are using AP and UPOD (which I assume is some variant of ActivityPods or SOLID) to connect smart home devices together? Very cool.

Would love to see some of these devices in action. My home is decidedly NOT all that smart because of the amount of cloud connections. I do have some smart devices (irrigation, thermostat), but trying to keep things minimal.

@silverpill @general so this is for embedded objects? That totally makes sense.

@evan This is my mistake, thanks for pointing out. It should be changed to "...where embedded objects are owned by another local actor".I think Create.object.attributedTo == Create.actor is a different thing, because it is related to authorization, whereas the requirement we're discussing here is related to authentication.In general, yes, none of this was built into ActivityPub. But over the years implementers figured out authentication and authorization on their own, and now this is how federation works. People expect that same-origin embeddings can be cached as is, without re-fetching.@general

@silverpill I don't think this makes sense: "Servers MUST NOT allow clients to publish activities where embedded objects are owned by another actor." We've never had this requirement; it's not built into ActivityPub; it's not how federation work.- Like- Announce- inReplyTo- Follow- Accept- RejectI think two way verification is a better mechanism than same-origin. So, check that the object of a Create has the same attributedTo as the actor.

@phnt Following on one of our conversations, I now call out authorized fetch as ineffective when it is used on public objects:Some servers require an HTTP signature in an attempt to limit access to public objects. In this scenario, the request is expected to be signed with a key that is owned by a server actor. However, this measure is ineffective and can easily be circumvented by changing the keyId parameter of a signature.

@julian@activitypub.spaceRegarding #Mastodon compatible polls, besides the the needs also to be considered.

Looking forward to participating in @evan@cosocial.ca's #evanpoll for real :stuck_out_tongue_closed_eyes: