@silverpill @julian

that's a bit simplistic imo. software doesn't matter, sure; what matters is what the software lets you *do*. but "interoperability" is not a goal in itself. it's a means to an end. for different software that let you do fundamentally different things in fundamentally different worldviews, there can be no meaningful interoperability.

example: fedi has concepts and abstractions for "posts" and "profiles". what happens when you don't have these same building blocks?

@silverpill @julian i posit a different goal, at least for myself: empowering people with effective tools by which they can express themselves.

i'm posting this from mastodon right now, but i could just as well be posting this locally from within nodeBB. the federation is irrelevant, and in some cases, the federation is actually a burden. it creates the seams in UX. federation is a boundary that information crosses. the goal of a discussion form is to get information across various interfaces.

@silverpill @julian reframing it in terms of information and interfaces, of data stores and transports, we find that there are multiple ways to participate in a centralized conversation:

- by web app + sign in (local or federated credentials)
- by HTTP POST to an endpoint (plus additional protocols on top)
- by emailing a certain address, if you wanted
- in theory you could physically send a letter to some building, if that was agreed upon beforehand, to manually enter it into the database...

@silverpill @julian so the exact protocol and its finer details are less important than what you can *do* with that. the goal is to make information reach your destination with minimal information loss.

in that sense, whatever subset of whatever fedi-adjacent protocol you adhere to is only useful insofar as it allows ingesting information without missing anything important.

and when it comes to publishing information (a separate concern from discussing!), you again likewise have interfaces...

@silverpill @julian

the primary publishing interface we have is the Web. that should be the primary focus, not "publishing to the fediverse". the fediverse shouldn't be the end-all-be-all. we shouldn't be poorly reinventing the Web from first principles.

in a similar vein, the "network" is made up not of fedi nodes, but of mutually intelligible interfaces for information. instead of negotiating an exchange of content, it is just as valid if not moreso to negotiate an exchange of *identity*.

@silverpill @julian given this framing, it is incredibly limiting to say "the network consists solely of URIs hosting JSON documents which contain an inbox and an RSA publicKey which is used to generate a Cavage draft 8 Signature on an AS2 Activity payload of a certain shape which is then delivered to another inbox via HTTP POST with a certain Content-Type, after which the activity will be unwrapped and discarded... no exceptions to any of this" (etc)

because maybe there's better ways.

@silverpill @julian

can the network not consist of all manner of agents whose identities can be established by all manner of methods? in the same way TLS negotiates an encryption suite, a generic "TLI" can be used to negotiate an identity proof without relying on TLS client certificates.

can the application layer not similarly negotiate a semantic profile for which data models, serializations, etc are supported, and what will be done with thr payload?

@silverpill @julian

that's a bit simplistic imo. software doesn't matter, sure; what matters is what the software lets you *do*. but "interoperability" is not a goal in itself. it's a means to an end. for different software that let you do fundamentally different things in fundamentally different worldviews, there can be no meaningful interoperability.

example: fedi has concepts and abstractions for "posts" and "profiles". what happens when you don't have these same building blocks?

@trwnh @julian Almost all social networks have profiles and posts.
If application is doing something completely different, then we don't need to interoperate. But within a federated social network interoperability is the goal because otherwise user experience is going to be poor.

@silverpill @trwnh @julian@community.nodebb.org Remember that one AI-based social network that said that they would never have follow relationships? Trying to imagine how to make that work with federation was a bit of a brain teaser. Their attempt at Mastodon interoperability fell apart for much simpler and much worse reasons though, so that experiment quickly turned into a nonstarter.

Maven Imported 1.12 Million Fediverse Posts (Updated) - We Distribute

A social network founded by a former OpenAI employee was caught importing public posts from Mastodon...and ran AI analysis to add tags to them.

We Distribute (wedistribute.org)

@julian@fietkau.social @silverpill @julian@community.nodebb.org i think the real question is what kind of world are we building here -- one limited to being a "social network"? that's so constrained. i don't want to live in that world. i don't want to "post" to "followers". i want to publish on my website and maybe syndicate to other websites of my explicit choosing. i want to be able to participate in discussions on various forums without having to make a new set of credentials for each one. neither of these require federation...

@trwnh @silverpill @julian@community.nodebb.org I guess we don't have to do pubsub if we don't want to. But addressing conversations to a closed circle of people instead of having everything public is something that, broadly generalizing, people want, so we probably want some form of identity management and authentication and recipient addressing. My gut feeling is at that point we're in "social network" territory. But I've never been someone to dwell much on semantics and I don't feel strongly about it here.

@julian@fietkau.social @silverpill @julian@community.nodebb.org that's basically just message passing. a message doesn't have to be a "post".

@julian@fietkau.social @silverpill @julian@community.nodebb.org to clarify: a message can also be a request, or a command, or a statement, or a query. we limit ourselves greatly when we think only in terms of “posts”. even within the limits of a “post”, we still have multiple contexts within which we can consider the message.

@scott those are all posts

this isnt about activitypub

@scott i mean “message” in the sense that raw HTTP requests and responses are “messages”.

@scott i mean “message” in the sense that raw HTTP requests and responses are “messages”.

@scott i want an ecosystem of standardized APIs with semantics beyond just “posts”. does that help?

i want an API to talk to people and machines in equal measure