Email or username:

Password:

Forgot your password?
Top-level
Gregory

@humanetech I did see it, but

- As with many SocialCG proposals, it's too theoretical. It's ideas built upon other ideas with what feels like no code written.
- It's per-instance. I'm looking for something per-actor, and preferably something that could be combined with privacy settings. Something that, given an actor and activity, could answer the question "can I send this actor this activity". The answer could be a simple yes/no but also something like "yes but only if they follow you".

10 comments
smallcircles (Humane Tech Now)

@grishka I understand. The Murmurations thing is a mere idea I want feedback on.

It is nothing more than a more cleaned-up well-structured document template as-a-profile + having them auto-aggregate so there's no manual work involved in bringing things together. Not per instance, but per app / codebase.

Note, I like your idea. Murmurations besides JSON-LD uses JSON Schema for validation, which *might* be used here too. Though that does not cover "yes but only if they follow you".

Just musing.

Sebastian Lasse, redaktor.me

@grishka @humanetech

w3.org/TR/activitypub/#conform and 2.1 “the entirety” – and the answer is yes.

But since many seem not to respect the protocol, full ack!
We need to specify it.
Very soon.

Gregory

@sl007 @humanetech here's the part of the spec that I don't think anyone at all respects.

But anyway, how does this help with capability negotiation? The spec is as vague as it could possibly be.

The end users doesn't care much about strict spec compliance. They will simply dislike this sloppy thing that allows them to send wall posts or friend requests or group invitations to servers that have no idea what those are. UX is extremely important if we want to end the Facebook hegemony.

Gregory

@sl007 @humanetech And I would even go as far as to say that protocol design should be driven by the UX and definitely not the other way around.

smallcircles (Humane Tech Now)

@grishka @sl007 or both ways, probably.

Important is.. the spec is out there for a while already, and it is not evolving. There's no 2.0 work underway.

This may not be bad or even needed, but then at least there should be a solid, well-oild FEP process or what-have-you-that-is-similar.

smallcircles (Humane Tech Now)

@grishka @sl007 question is, who is doing it, if no one has the time because they are involved in app development or research of related-but-different standards?

Gregory

@humanetech @sl007 at some point we will end up with suboptimal de-facto standards. That's what always happens.

smallcircles (Humane Tech Now)

@grishka @sl007 the spec is intentionally vague, because at the time the idea was that 'feature-complete' thing was too complex, and would lead to the pitfall of being overspec'ed (which is what many W3C specs suffered from.. XML et al anyone?).

A good decision at the time, imho, but now it starts to be a burden and is diverging the fedi into custom app space.

Gregory

@humanetech @sl007 what do you mean by custom apps?

With capability negotiation I only want one thing: if two implementations have feature sets that intersect, they should be interoperable within this intersection. So if I have walls, and someone else does too, they should work across our implementations. So basically you would say "I implement this protocol extension" and all other servers that know what it is will pick it up.

I should probably look at how XMPP does it with its XEPs.

smallcircles (Humane Tech Now)

@grishka @sl007

I was generally speaking in reaction to Sebastian and AS/AP having holes for devs to fill in to their own design, which leads to divergence.

Am in favour of capability negotation. I believe in the past it was discussed (but in the context of NodeInfo vNext), was seen as too complex, and a temporary compromise in form of FEDERATION.md came up, until we'd tackle it later. So maybe now is that time :)

Yes, we may have FEP + XEP pairs, instead of v2 specs.

Go Up