NodeBB-ActivityPub Bridge Test Instance

Everyone’s busy building admin tooling for shared block lists when what they could be building is structured “threat intelligence”

Which is kind of the same data (Except with much more focus on timestamps & description), its just the UI and how the data is consumed is different (rather than automatically blocking/unblocking things I get a queue of notifications I can act on)

Does it mitigate all of the issues that exist with shared blocklists? No, because those are human nature. An admin can decide to just blindly follow recommendations without doing their own investigations and there’s nothing you can do about it.

Does it mitigate all of the worst aspects? Yes.

Is it something you can build and deploy without doing complicated protocol development as might be required for something more ideal? Yes.

In a way, it’s a bit harder for me to talk about the values and design goals of ActivityPub. It happened in a larger standards group and involved a lot of passing of hands. I think if I were to be robust about it, I would also ask Evan Prodromou, Erin Shepherd, and Amy Guy to weigh in, and maybe they should; I think it would be nice to hear.

The goal of ActivityPub to me, only partially realised in the decade since, was to function as a substrate to enable multiple social applications to exist within a single social graph; so that we could experiment with ideas other than (and perhaps radically different from) Twitter clones.

In some ways I felt that the C2S API was more important than S2S - the original drafts of the spec made S2S optional, but mandated C2S. Its funny and in some ways unfortunate how that flipped.

@cwebber

RE: https://social.coop/@cwebber/113647109852249805

IANA.org is down, post unapproved protocol extensions

@trwnh @jbqueru I think attempting any form of normalisation (beyond that specified by the URL spec) without involving the defining server is a complete fools errand tbh.

@trwnh @evan @evan @julian @silverpill and to be clear my ambivalence about whether there should be a thread object comes primarily because I don't think this is a point on which we will ever get universal agreement

It's an area where I feel the only real route is the "why not both?" compromise that doesn't really make anyone happy

@trwnh @silverpill @evan @julian @evan so, truthfully, I'm ambivalent to whether a thread object exists. But if it does, I feel like it should probably be reified distinctly from the thread collection primarily because I don't think treating collections as objects is a good idea. Maybe I'm wrong, but that's my strongly held opinion!

And yeah, then we can give threads a following collection and let people follow them as they wish.

@trwnh @julian @evan @silverpill I never did the URI should be opaque; what I implied was that perhaps it should be an implementation detail URI as opposed to a directly visible one.

Some of this is that I wonder how decoupled such a thread truly is *semantically* from it's root post

@trwnh @julian @silverpill (the other option is instead of redirection do <link> tags, and then you can link to both if you wish; imagine including <link rel="as:context" href="...">)

@trwnh @julian @silverpill I think the question here is "does a thread actually have any distinct properties of its own?"

Maybe a title, but that can also be inherited from either the first or most recent post. Many threaded discussion systems don't have thread objects at all, of course (email is perhaps the canonical example)

So I lean towards the idea that you should just redirect to the first thread in the post, and place the context (which when becomes just a collection of in-thread posts; an implementation detail) at another URL where it mostly becomes invisible to users.

And I think that's better, especially because having significant semantics on collections starts getting confusing when e.g. you have collection pages flying around

Really I think most types which can be represented directly as a collection (e.g. image galleries) are best represented as an object that possess a collection, though not everyone might agree

@darius @trwnh I don't even like that I need to have an alt. We have Google+ esque circles in the protocol, I should be asleep to use them

(And don't get me started on the fact that replies to my followers only posts get addressed to the replying person's followers)

@trwnh @darius more specifically if *I* have multiple actors I want to it be around multiple facets of myself, not dictated by technological constraints or similar

@trwnh @darius you want more actors, I want less actors

This, obviously, means war

@trwnh @darius I guess that's where I think your inbox is your actors inbox but not necessarily "your" inbox

Things like Update and Delete activities aren't really for your attention; they're just for endpoint synchronisation

@trwnh @darius I actually think this demonstrates a fundamental flaw in the email model

There are times you want to be able to do endpoint to endpoint but potentially automatic message exchanges, and email doesn't really have a mechanism for doing this

The straightforward example is my client noticing your S/MIME or GPG key is expiring and asking if there's a new one

@laurenshof @darius @trwnh ... Things I have been shouting for literally a decade!

@trwnh @darius I think personally I lean towards a pure firehose model. Send me everything you got and let my clients pull out the data they're interested in

In part because we're unlikely to ever agree on one exact axis of filtering

@trwnh @hongminhee @julian @michael @mike @pfefferle @renchap @thisismissem if we got to do a clean slate do over, I'd commit to either full unification or separation of objects and activities, and also the "implicit collections" would not be reified as Objects (ideally we'd get structural addressing too: you'd be able to explicitly refer to a users followers - for example - without having to know the URL of the collection)

@trwnh @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap and I agree, but I think this approach if actually implemented really combinatorially explodes the protocol. An implication of this direction of thought is that your like has a likes collection, and that likes collection has it's own likes collection, ad infinitum.

You really can express absolutely everything in ActivityPub/AS2 and it's it's biggest flaw IMO. The combinatorial explosion really paralyses implementers

@trwnh I love how as we hash this out it turns out the two of us are in violent agreement and we're just disagreeing on the way to proceed from what exists

@hongminhee @julian @michael @mike @pfefferle @renchap @thisismissem @trwnh if you treat activities as first class objects indeed of second class, it really opens up various cans of worms. What does it mean to like a like? Can you reply to an EmojiReact? Can you Like a Listen?

The end result of dividing things might be some semantic overlap between "small" Activities and "large" Objects, but that's probably not the worst possible argument

I do think there's an argument for a world with an activity-object merge but it's probably the world in which the Create activity never existed