Skip to main content


 
I wrote an answer to Dennis post https://schub.io/blog/2018/02/01/activitypub-one-protocol-to-rule-them-all.html about #ActivityPub

Very cool! Thanks!

Hmm, I had some small comments on it, I'll read it again tomorrow on a bigger screen 😁

Well done, nice text!

Great post. Will keep it because there is a lot info about some technical stuff I was about to ask anyway ;) Thanks a lot.
This entry was edited (3 months ago)

Most current implementers have integrated Webfinger for that purpose, since users like to work with handles rather than URLs. So although not explicitly specified, this is a fine solution for the problem.
diaspora*-protocol also uses webfinger to get an hcard to a given handle.
Dennis says that it isn’t defined that you have to use authentication when pulling non-public content. But: It is surely a bug when someone wouldn’t do so, and in fact all systems that I have tested, are acting that way or prohibiting access to all non-public content.
If it is not defined that you have to authenticate, is defined how you could authenticate when fetching posts?
“aspects”
Diaspora uses so-called “aspects” which are collections of persons that have a relationship with the respective user. When creating a post to such an “aspect”, in ActivityPub you would simply collect the list of persons in that aspect and direct the post to their inboxes. (Optionally -
... show more

I think you've got it backwards, @Deus Figendi. The point of @Michael Vogel was to explain that what was already done with the Diaspora protocol can also be done with ActivityPub.

My blog post is an answer to Dennis blog post. Every paragraph answers an aspect of his post. This post is not about what the Diaspora protocol is able to do. It is about what AP is able to do - and in fact (with the exception of private messaging) AP would be able to cover most parts of the requirements.

I don't know if there ever will be AP in Diaspora and I'm no advocate in this direction. I only wanted to state my personal view about the protocol. It has got problems, but there are workarounds. I also prefer AP before DFRN (our own protocol). When the last problems had been solved, the transition from DFRN to AP will begin. Then the whole communication will be done over AP.

I think you’ve got it backwards, @Deus Figendi. The point of @Michael Vogel was to explain that what was already done with the Diaspora protocol can also be done with ActivityPub.
No, @Michael Vogel was explaining what/how diaspora* would have to do to be able to work with AP. And in many cases it's already as Michael says.

@Michael Vogel du könntest das auch nochmal neu Posten mit #diaspora Tag. dann lesen das.noch mehr Leute.

To clarify: I guess Dennis and me, we both are just having a different look at the specification. Dennis is looking in a theoretical way on it (and thus finding several design flaws). He is mostly following the specs by word. (This is - I want to emphasize this - not meant as an accusation)

I - in difference - am a very pragmatic person. I'm following specs mostly by their intention and I'm looking how to implement it, most possibly by looking how others implemented it - and possibly create some workaround.

I think that you need both types of persons - and most likely there are specs where my way of working would be a disaster. For AP, I guess, this is the best way.

@heluecht Not having read any of your both' blog posts, just reading your toot, I'd say I'd prefer specs and implementations where both approaches lead to same results. Meaning: Specs should be written in an unambiguous way and implementers should not silently deviate from them but press for a change of the specifications if they don't work or don't make sense.🤔
But maybe I am missing the point, not having read your posts 😉

In the case of ActivityPub, it kind of resolved itself: since Mastodon was the first popular platform to implement ActivityPub, they settled a number of debate about the imprecision of the spec itself, which lead subsequent implementation to have the option of following the same implementation.

@heluecht
I feel similarly. I think ActivityPub is good enough for most use cases, and certainly good enough to power a new generation of federated social networks. At the same time though, I think a lot of Dennis's points are well-said and will need to be addressed at some point. The work that the Pleroma devs are doing with Litepub is moving in the right direction, as long as we can avoid fracturing the network with a fork.

I think that we need some kind of board where implementers can discuss about how to implement specific things.

@heluecht For sure, that would be really helpful. The SocialCG IRC channel is usually filled with people who want to talk about that sort of thing, but I don't IRC is a great format for those discussions - it would be better to have a forum where everything is indexed and searchable

Something more "offlineable" would be better, indead.

Maybe a discourse, maybe someone can sponsor that for the "Fediverse", maybe some hoster. Sometimes they do things like that.

I think that we need some kind of board where implementers can discuss about how to implement specific things.
It bewilders me that there is always a kind of intent to "escape" to somewhere else, instead of trying to find ways to do it inside the frederation/fediverse. I saw it the first time in the early stages of D* and it looked like an escape from the (awfull) noise common users create with their "we need/want this or that .." and trolling criticism.

Shouldn't github be by default the place for those discussions?

I find it quite disruptive to have to go to X other services and just don't get what sense it makes to go to centralized services for to work out how to improve a decentralized web.

but that's probably just me ..

Well, the #Fediverse is fractured into different parts, #Mastodon users (programmers) could then not communicated with #Diaspora users. #Github got kind of evil because of #Microsoft ...

instead of trying to find ways to do it inside the frederation/fediverse

Well, the #Fediverse is fractured into different parts, #Mastodon users (programmers) could then not communicated with #Diaspora users. #Github got kind of evil because of #Microsoft

"offtopic":
I knew the microsoft issue would come up ..
that's just kinda "different" battleground, although actually proves my centralized dependency point when it comes to: "let's discuss inside our realm!"
For me it's kinda strange that any coder of the federation-fediverse hasn't an account with any of the competetive but befriended pr... show more

It is very comprehensive, still misled. Why don’t you trust people actually working on #Fediverse projects when it comes to set up a centralized communication channel?

It’s not distrust, I feel it like incoherent, like we are working on a communication system but not using it for communication.

The key is that we are working on separate communication systems. Nobody wants to use any other Fediverse system they aren’t working on. Sure, we have test accounts everywhere, but that’s pretty much all they are.

Choosing an external service outside of the federation ensures that nobody is actually working on it, so it’s “neutral grounds”. This is important because the reason why there are multiple systems in the first place is that we disagree on a lot of stuff, and the thing we should be least disagreeing on should be the centralized communication channel.

Remember, everyone’s acting coherently from their point of view. If you see some incoherence in anyone’s behavior, you just are missing something or projecting your own opionion on them.

For me it’s kinda strange that any coder of the federation-fediverse hasn’t an account with any of the competetive but befriended projects.
I think this is a good point. I have accounts on many systems specifically so I can see it from the user's perspective on each not just my own that I happen to operate in mostly throughout the day. It also helps give me ideas of what works and what doesn't in how the various systems do things. It costs nothing but a little time to set up an account and dabble with it from time to time.

I agree @Hypolite Petovan (he/him), that's the basic difference in point of view.

I'm looking at it from the point of view of a user who just want's to talk with everyone, expecting wallet gardens to disappear and considers that that's the common goal, meanwhile the different projects look at it from there individual perspective and goals.

Normally I call that the difference between left (common interest) and right (individual interest) where depending on the level of perspective a personal goal becomes apparently contrary to the common goal.

That's why I talk aboutthe need for "moderation" I guess, to find the best common ground.
But to be clear, healthy, sane and social should be to be pleased to be a guest on a different system and being treated as such

instead of the need of neutral ground.
Bild/Foto