Email or username:

Password:

Forgot your password?
All posts smallcircles (Humane Tech Now)'s posts Post Back to profile
smallcircles (Humane Tech Now)

At #SocialHub we need to think about next stages of #fediverse development.

Do we still think too small?

What I observe is that - while federated #activitypub apps are the goal - application design approach is more or less as follows:

- I want forum → I develop forum → How can forum federate?
- I want video → I develop video → How can video federate?

As a result we get Microblogging-enabled apps. But what does true #interoperability of @activitypub apps look like?

socialhub.activitypub.rocks/t/

2 Apr 2021 at 6:12 | Open on mastodon.social
31 comments
Gregory

@humanetech IMO "true interoperability" between disparate software should be such that only the features that intersect between the two are interoperable. For example, if someone makes a hypothetical forum, it won't make much sense for it to interoperate with Mastodon. It totally could, but that would be detrimental to the UX.

For example, Smithereen groups and walls aren't interoperable with the existing microblogging software, and it's fine.

4 Apr 2021 at 14:16 | Open on mastodon.social
Sebastian Lasse, redaktor.me

@grishka @humanetech

No, it would NOT be detrimental to the UX.
This is what Gestalt Principles is about and also my Talk for ActivityPub Conf was about.

This is stealing content and hiding content for the user.
If my friend on software bar decides to send me official type="xy" to my software foo the whole sense of the official protocol is that I get it !!!

“THE ENTIRETY” w3.org/TR/activitypub/#conform

@grishka @humanetech

No, it would NOT be detrimental to the UX.
This is what Gestalt Principles is about and also my Talk for ActivityPub Conf was about.

This is stealing content and hiding content for the user.
If my friend on software bar decides to send me official type="xy" to my software foo the whole sense of the official protocol is that I get it !!!

4 Apr 2021 at 14:23 | Open on mastodon.social
Sebastian Lasse, redaktor.me

@grishka @humanetech

So, one wish:
If someone decides to show only a subset of an official protocol please do not pretend, it is the official protocol.
This is a very bad behaviour.

4 Apr 2021 at 14:24 | Open on mastodon.social
Gregory

@sl007 @humanetech no, of course there needs to be capability negotiation. Your friend shouldn't have been able to send you this thing in the first place, and should see an indication somewhere that your instance doesn't support that thing.

Here's how I do it — this is a Lemmy community:
4 Apr 2021 at 14:28 | Open on mastodon.social
Sebastian Lasse, redaktor.me

@grishka @humanetech

I would not say “There needs to be”, I would say “There should have been”.
It is too late know since the protocol is written.

It is now the same than saying:
I am http compatible but I only support DELETE requests :)

4 Apr 2021 at 14:31 | Open on mastodon.social
Gregory

@sl007 @humanetech LOL. Well, yes, there is a de-facto "baseline" subset of ActivityPub that everything is expected to support, which is mostly microblogging stuff. But since what I'm doing requires extending ActivityPub far into an uncharted territory, I'm being careful to strike the balance between usability and compatibility.

4 Apr 2021 at 14:37 | Open on mastodon.social
Sebastian Lasse, redaktor.me
Gregory

@sl007 @humanetech Actually, I since moved away from using NodeInfo for compatibility and ended up doing it per-actor. For example, I assume that an actor doesn't support wall posts unless there's a `sm:wall` key with a URI that points to a collection.

4 Apr 2021 at 14:44 | Open on mastodon.social
smallcircles (Humane Tech Now)

@sl007

> Exactly this destroyed the protocol

The #activitypub protocol is not broken in any way, it just found early adopters in a Microblogging domain, which is logical since it provides social media primitives.

I agree with @grishka that once we start adding app-specific #linkeddata extensions, there's no sense having full compatibility with all other app domains that exist.

That also includes AS primitives, where semantics may differ. Compat most important for AP communication mechanism.

4 Apr 2021 at 15:25 | Open on mastodon.social
Sebastian Lasse, redaktor.me

@humanetech @grishka

The “extensions” was not what we were talking about, that was Grishkas answer related to NodeInfo.
Wall posts are NOT specified in ActivityPub.
It is only about the Core properties and I think the specifications are well written.

An “extension” does not help here at all.

4 Apr 2021 at 15:30 | Open on mastodon.social
Gregory

@sl007 @humanetech Problem is, the AP spec is deliberately very vague and domain-unspecific. But its real-world implementations are concrete and interpret everything in the context of their domain.

Core properties can be, and often are, also interpreted differently depending on the domain. So in that sense they aren't very much different from extensions many projects declare in their own namespaces, except that they have somewhat similar meanings across implementations.

4 Apr 2021 at 15:35 | Open on mastodon.social
Gregory

@sl007 @humanetech So, for example, there's the Follow activity. Everyone knows what that does, right? Wrong.

You can Follow people in a social media service. But you can't in a forum. There you could, for example, follow a topic or a subforum to get notified about new posts. It's two vastly different domains that use the exact same vocabulary in logically incompatible ways.

4 Apr 2021 at 15:39 | Open on mastodon.social
smallcircles (Humane Tech Now)

@grishka yes, it is the same problem as the semantic web had.

I saw @sl007 mention DELETE. If you look at Rest it is also vaguely defined, everyone doing it differently. You might only support GET and POST, have different API designs. It is not ideal at all, but it has proven to be practical.

In @activitypub et al there should be accepted ways and best-practices and standardization-as-much-as-possible. Closed vocabulary extensions.

I am less worried about big players doing things differently.

4 Apr 2021 at 15:41 | Open on mastodon.social
Sebastian Lasse, redaktor.me

@grishka @humanetech

Sorry, every ActivityPub actor can be followed.
That makes no sense to me.
Even in the discourse ActivityPub proposal (“Forum”) you were able to follow.

“interpret everything in the context of their domain.”
is exactly the opposite of
“fediverse” !

4 Apr 2021 at 15:42 | Open on mastodon.social
Gregory

@sl007 @humanetech So how could we then have any diversity in the feature sets of the fediverse software?

4 Apr 2021 at 15:43 | Open on mastodon.social
Gregory

@sl007 @humanetech my point being, following people in a forum is a rare and rarely used feature. Not all forum engines have it. PhpBB, one of the most popular ones, certainly doesn't.

4 Apr 2021 at 15:46 | Open on mastodon.social
Sebastian Lasse, redaktor.me

@grishka @humanetech

My first and most simple idea:
By attaching the link to the original full post so that people do not loose their content.
Even if it shows me a json telling me that my best friend was gifted a son, I would be very happy to know, no matter if styled or json.

Better would either be simply concat (the multiple values problem) and bridging to supported types.
Better would also be an additional generic inbox UI (like DM here) showing it as a minimal representation.

4 Apr 2021 at 15:49 | Open on mastodon.social
Gregory

@sl007 @humanetech You keep saying that as if it's possible to have someone send you an activity your software doesn't support. The whole point of having capability negotiation is to solve this very problem before it has a chance to happen.

4 Apr 2021 at 15:51 | Open on mastodon.social
smallcircles (Humane Tech Now)

@sl007

I agree with @grishka

Every activity has different interpretations depending on the domain it is used in. In a webshop you might have as:Offer literally meaning something that is for sale.

But Offer is already being used in other contexts.

In #forgefed an as:Note is a comment to a Ticket or Merge Request.

etc.

4 Apr 2021 at 15:53 | Open on mastodon.social
Gregory

@humanetech @sl007 Yeah. I use Offer{Follow} as a friend request. But I only send it to actors that have supportsFriendRequests=true. I change my UI accordingly.

4 Apr 2021 at 15:55 | Open on mastodon.social
Sebastian Lasse, redaktor.me

@grishka @humanetech

Citing the spec. again
“Actor objects MUST have, in addition to the properties mandated by 3.1 Object Identifiers, the following properties:”
Followers / Following

please note that MUST is written in capital letters for a purpose.

4 Apr 2021 at 15:57 | Open on mastodon.social
smallcircles (Humane Tech Now)

@sl007 @grishka

But does it say what Followers / Following means? What if I have completely different custom actor types..

Tim Berners-Lee's Semantic Web failed because there was they idea to have universal semantics that applied globally.

It is very important to have closed vocabularies, imho, where the terminology only have well-defined meaning in a specific domain.

This matches the idea of domain-driven design (DDD) where you have bounded contexts.

4 Apr 2021 at 15:59 | Open on mastodon.social
Gregory

@humanetech @sl007 You would technically follow the spec if you have these collections, return them as always empty, and send Reject{Follow} for any Follow you receive.

4 Apr 2021 at 16:00 | Open on mastodon.social
Gregory

@sl007 @humanetech Actually, attributedTo seems to be the standard way to represent group admins/moderators at this point — except Lemmy returns them as an array of IDs instead of objects. Added support for that because why not. Here's how it looks now.
4 Apr 2021 at 20:32 | Open on mastodon.social
Sebastian Lasse, redaktor.me

@grishka @humanetech

Returning them as an array is correct cause it can be multiple.
Doing the same, see e.g. in the client github.com/redaktor/widgets-pr

Having also support for an array of IDs (as long it is an URL.protocol I can deal with) cause it is specified as being valid.
“Range: Link | Object”
see also Example 68
w3.org/TR/activitystreams-voca

4 Apr 2021 at 21:04 | Open on mastodon.social
Sebastian Lasse, redaktor.me

@grishka @humanetech

Additionally the array would then only need a .filter for the Actor type because

“The attributed entities might not be Actors. For instance, an object might be attributed to the completion of another activity.”

4 Apr 2021 at 21:06 | Open on mastodon.social
Gregory

@sl007 @humanetech I already do this exact thing (User extends Actor, groups can't be admins in groups)

This universal object dependency resolving I recently wrote simplified my code so much :)
4 Apr 2021 at 21:09 | Open on mastodon.social
Sebastian Lasse, redaktor.me

@grishka @humanetech

Very nice!
No doubt that e.g. redaktor and smithereen will work perfectly together!

4 Apr 2021 at 21:26 | Open on mastodon.social
Go Up