Changes to the diaspora protocol

Federation
21

I agree with @jasonrobinson that a protocol change should be communicated before it is done. That’s why I agree with the proposal.

@dennisschubert if you add some more validation there is always a chance to break things, that’s clear. Just by knowing that you are working on (for example) more validations to the “host-meta” data would enable me to compare the Friendica part with the Diaspora part. I could compare if we are sending the same content type, if the XML is really validating, if every information is provided, …

And an information like “we will remove the data for xyz at this place, please take the information from that place” would help as well.

BTW: You wrote “… but it has worked with some hacks on both sides” and then you wrote “We do not have exceptions for friendica”. The first sentence sounded for me like “we made some exceptions”. Maybe I was misinterpreting it.

22

We’re not talking about supporting a broken protocol. It’s great that you are working on a better protocol and better federation, but the only question is if you can (in time) communicate relevant changes to the other projects in ‘the Federation’. So these project can adapt and people on these project can still communicate with Diaspora users. Eventually it’s all people who wants to keep communicating.

That said, I think it will be a splendid idea if Diaspora can officially make some kind of documented federation API available.

That said, a separate project/library for federation should be our final coal.

23

I guess we have the feedback of the people that matter.

Since it’s commit messages that are need to be followed (according to Benjamin), maybe someone can start following the work so everybody interested doesn’t have to do it separately. I’m not interested in trying to follow the things re The Federation any more (which I guess is dead on arrival) with the attitude on our side.

I guess also this means that we’re not any more interested in the SocialWG work since, unknown to me, you’re talking about making a proper implementation of the current non-protocol. I was under the impression, as a core project member, that we were only extracting the current code out and then possibly adopting something else like the SocialWG work. I guess before you spend countless hours on the protocol work it would be nice to discuss these things within even core team members - or is that just Jonne and Dennis now?

Thanks Dennis for your constant attitude regarding anyone else, including other core members.

I think I’ll take a little breather on the 1-2 hours a day I spend on mainly promoting diaspora and the federation, and supporting diaspora users via various channels. If someone else wants to do some of that, let me know and I’ll set you up with some access to the accounts. Clearly, consulting other core team members is not needed in this project where communication is not wanted by a certain part of the core.

Sorry for dragging you all into this. Dennis is btw the reason we are talking here because he refused to argue these points in private messages where this all started.

24

I’m sure anyone doing it is simply looking to reach our userbase

Not our userbase. The users. They don’t belong to us. And no, I don’t find revolting they are trying to build bridges between networks.

Or do you think it is more important to “try” to support friendica, redmatrix and hubzilla than a better federation for all diaspora users?

I think what he found more important was just talk. And I don’t understand why it is making you angry…

To be honest, it looks like neither @augier nor @mikemacgirvin and @michaelvogel have actually read the comments and the original proposal, which makes me angry as hell. Thanks for voting and commenting without knowing what is actually going on.

You seem angry very often… And I thank you considering me stupid… I voted before you wrote your comment an even when I read it, I still find it irrelevant. Sorry you don’t like it, but it stays this way.

Well, but that is what the proposal suggests.

Do not merge in changes before listening to all the stakeholders and noting their concerns with implementation and timetable

I don’t understand it this way. If one of the stakholders clearly don’t give a fuck and never give any feedback, then ok, this won’t be a veto and I really don’t think @jasonrobinson has ever considered this way. But there’s a huge gap between this point and @jhass or @dennisschubert’s position of “I don’t care about others. All that counts is diaspora”.

that we were only extracting the current code out and then possibly adopting something else like the SocialWG work.

I had too.

25

I would propose a new mailing list especially for developers of all different projects who are coding with the protocol. This new list should exclusively be used for having a shortcut when (by mistake) something broke in the communication between the systems or when there are questions concerning the implementation. I guess this would be a very low volume list since mostly the communication is working fine between the systems.

@jhass Once again: I’m sorry that I participated that late on the nodeinfo stuff. Due to too much work on my side it went out of my focus. Additionally I’m getting lost in the various communication channels that are used at Diaspora.

26

this all seems to tie into the development of an API, i mean to some extent the application developers and collaborating networks are in exposed to these issues because there is no API for them?

27

No. The missing of an API has nothing to do with it. An API is for using your existing account on a system in another way (maybe from a mobile client). Here it is a question concerning the protocol.

28

@michaelvogel

Just by knowing that you are working on (for example) more validations to the “host-meta” data would enable me to compare the Friendica part with the Diaspora part. I could compare if we are sending the same content type, if the XML is really validating, if every information is provided, …

The relevant issue is #5114 and the repo for the gem code is SuperTux88/diaspora_federation. Maybe you could just follow that issue and we will leave a comment whenever there is a pull requests that removes federation code from the diaspora codebase and uses the gem instead? One could then discuss on github or on IRC if those changes will affect Friendica.

Of course, planned breaking changes (which make the protocol incompatible with old d* versions) will be announced early enough so you can adopt your implementation.

@jasonrobinson

Since it’s commit messages that are need to be followed (according to Benjamin)

Where did he write that? Benjamin wrote

The only planned changes are not new: #2440 and #5963. And as I said, these will be added backward compatible. I will notify friendica, redmatrix and hubzilla before I remove the old implementation of these issues.

I guess also this means that we’re not any more interested in the SocialWG work […]. I was under the impression, as a core project member, that we were only extracting the current code out and then possibly adopting something else like the SocialWG work.

Benjamin is extracting the current code into a gem. While doing that he also started to fix some open issues. The SocialWG works is not done yet and we don’t know if we can use it for diaspora*. Moving the federation to a gem makes it much easier to adopt another protocol later. We might even support more than one protocol, who knows. The SocialWG works sounds promising, but I don’t think we should stop fixing our own protocol.

29

okay. well. i like the idea of a heads up mailing list. the devs make a huge investment in time and all contribute unique skills, so it is a shame when efforts nullify instead of being added together to improve my Favorited social platform :slight_smile:

30

@steffenvanbergerem My problem is that I don’t know any Ruby at all. I don’t know the structure of Ruby (how the different parts are working together) and I don’t know the structure of how Diaspora is working. Just having the the pull requests doesn’t help me much.

I will follow that issue but will need explanations.

31

@jasonrobinson

Since it’s commit messages that are need to be followed (according to Benjamin)

I have never said that, but if you want to be informed about every little change, then it is the easiest way to follow the development (I try to write informative commit messages). If you only want to be informed about breaking changes, then it is NOT necessary to follow the commits.

you’re talking about making a proper implementation of the current non-protocol.

Yes, this is the first step. After the federation code is in its own gem, it is easier to replace the protocol or add a second.

The diaspora core developers do not want to communicate changes.

This is not true! But I can not wait for approval of everybody. I WILL inform everybody BEFORE something old is removed.

As I understand it now: friendica and redmatrix don’t want a veto and we don’t want to wait for a veto. They want to be informed before something is removed, and we will inform them before something is removed. Where is your problem?

@michaelvogel

I agree with @jasonrobinson that a protocol change should be communicated before it is done.

There is not ONE “before it is done”. The protocol changes will always be in two steps: 1. add something new and still support the old. and 2. remove the old. The proposal was about inform you before step 1 and wait for your feedback, before we even do some changes. My plan was to inform you before step 2, while the old stuff still is supported. But before step 2 we have a working reference implementation, documentation and enough time for you to add the changes to your software.

Additionally I’m getting lost in the various communication channels that are used at Diaspora.

I don’t know if it makes it better by adding another mailing list :wink:

My problem is that I don’t know any Ruby at all.

You don’t need to know any Ruby. I will inform you about the big changes. And if you want to be informed about every little change, then it is maybe indeed better to follow the commits. But the commit-messages should say enough for you to see if it is maybe important for you. And for example the validators are easy to read: webfinger and HCard and if you have any questions you can always ask me. There is also a documentation of the gem where the entities are documented (webfinger and HCard) with deprecation warnings. But also here, you can always ask me, if you have a question.

32

Dennis is btw the reason we are talking here because he refused to argue these points in private messages where this all started.

So are we ad hominem now? You wrote a private message to Jonne and me claiming we do decisions without involving the community. I refused to discuss this in a private conversation you started and take it into the public as you wished. And now I am the bad guy for bringing this into the public? What is wrong with you?

I am seriously shocked. I thought we had a nice collaboration going and now I feel like you played me for a sucker. This whole discussion which started as an important discussion for this project turned out to be a campaign to make people look bad. This is a very uncool move, Jason. I am disappointed and I am very sad about this has come so far. What’s your point of doing that? Seriously?

We’re now discussing in an endless loop about stuff we already do agree (that is, announcing breaking changes before doing them). We never planned to break stuff without announcing it but you claimed otherwise. Now other people think we’re breaking stuff without notice and thus accepting this proposal without getting the core of it. Your proposal is not about communicating changes, it is about waiting for everyone else to say “okay, you are allowed to make changes” which will kill this project.

Why did you even close this vote? You complain about our lack of community involvement and now you are the one closing this discussion? The outcome you set was not even part of the proposal. I thought I knew you, but this is an action I’d expect from a troll or someone who is seriously trying to hurt the community and not from a valuable community member.

I did not even block the proposal because I would be able to accept the results. I made clear I would not be able to justify my time anymore when the project decides to accept your proposal, but I never said this is something that could not be done.

I made it clear before, but as long as I am part of the development team (that is, as long as there is no proposal against me), I will add my opinion to discussions. In fact, you even asked Jonne and me for our opinions and we made it pretty clear. And now you’re not able to accept it because you think we are wrong? And because you think we are wrong you are not able to discuss in a peaceful matter?

This is just sad.

33

@supertux88

This is not true! But I can not wait for approval of everybody. I WILL inform everybody BEFORE something old is removed.

Great, I like the “everybody”! Why did you disagree on the vote then? Maybe you can talk Dennis and Jonne to agree with you then. Since they only promise Diaspora support, not recognizing any other implementers.

@dennisschubert

I am disappointed and I am very sad about this has come so far. What’s your point of doing that? Seriously?

I guess I’m just tired of your constant hostile attitude and this can be considered just tipping over. I opened this proposal to get some kind of promise that there is no need to get back to this subject but as you basically presented a big NO brick wall as response - well, no point in discussing then is there?

We never planned to break stuff without announcing it but you claimed otherwise.

You specifically said privately and publicly you will not care about other than Diaspora implementers - is that correct or not? You also defined no need to support external services, by for example doing a patch when federation breaks. I even said I would do the work. But to you anything outside Diaspora is not important.

Why did you even close this vote?

I closed it so that it will not pass. So that you will not stop work on the Diaspora protocol, as per your very strong ultimatum. I think that would be worse for Diaspora than forcing the vote through.

So your ultimatum worked.

And now you’re not able to accept it because you think we are wrong? And because you think we are wrong you are not able to discuss in a peaceful matter?

You’re not discussing - you are putting your foot down with a strong opinion which I tend to disagree very strongly on. The Federation is more important than Diaspora. You and Jonne think it is not important at all and you at least said clearly if you have to consider federation with the other implementers, you will quit working on the protocol. That is a pretty damn strong statement with very little discussion in it.

I strongly agree work has to be done on the federation protocol. I totally support moving it out to a gem. I want it to continue.

What I don’t agree with is your “fuck all the rest” attitude when it comes to anyone else.

I’m not the easiest person to deal with but you are a fucking brick wall. When there is no dialogue, why try? I’m at least not going to waste any more time on it. You guys are much more important to Diaspora than I am.

Currently I don’t see the point of promoting The Federation as it clearly is not something that is important for all the project members.

34

Great, I like the “everybody”! Why did you disagree on the vote then? Maybe you can talk Dennis and Jonne to agree with you then. Since they only promise Diaspora support, not recognizing any other implementers.

I disagreed because I don’t agree with “Deliver a plan of changes being done to stakeholders when those are planned or latest when work begins on them” and also I don’t agree with this from the OP “Even if it is “YOLO code”, coming from one developer, that doesn’t mean it doesn’t have to be supported, maintained and more importantly, not broken for ALL stakeholders.”

And I think Dennis and Jonne agree with me here, because Dennis wrote “This will be done after a long pre-announcement …” in his first comment. The “we don’t care” (and this is not a “fuck all the rest”) is because we can’t guarantee that the other networks don’t break because the current protocol is unstable, and so we can’t support them officially. We don’t plan to break it without announcement, because all planned breaking changes will be backward compatible for some time. But we can not guarantee that any other “non-breaking-change” doesn’t break something on their side (like #6405, this was not a planned breaking change).

I think you are mixing these two things here: 1. planned breaking changes (this will be backward compatible and communicated early enough) and 2. unintentionally broke something (we can’t guarantee that this won’t happen again with third party networks at the moment)

I agree with you, that we need to officially support friendica and redmatrix, but we are not there yet. We need first a defined protocol which works stable, and then we can support this protocol. If others then implement this protocol, they are automatically supported (if they implemented it correct).

35

I agree with you, that we need to officially support friendica and redmatrix, but we are not there yet.

What does “support officially” even mean if Friendica and Redmatrix are the ones supporting Diaspora? That wouldn’t even be possible. I don’t even know what that would mean and I certainly haven’t requested it or seen anyone else request it.

What I see is a lack of will to collaborate at all, even to the level of being hostile, unwelcoming and publicly announcing not caring at all. And no, I’m not talking about you.

Maybe things will grow to be better but tbh I don’t have that much faith. Take NodeInfo for example, again. Jonne writes the spec for it and asks me to pass it on. I pass it on at some point afaicr, but didn’t have any immediate concerns with it. Later, we agree that it is time to implement it. Then when people actually give feedback, it is too late and not welcome.

I fear the same will just happen with the protocol changes. There is just no interest to ease interop. Any comments will be shot down as “not your business, implement if you want but we don’t care” - and I wouldn’t be surprised if the exact words wouldn’t be just those.

Well, these are my feelings on the comments made by certain core developers here and in the afore mentioned private discussion, and before too and they are frankly killing my interest in contributing to the project at the moment.

I’m not going away (sorry), or trying to hurt the project, but I think I am allowed to say what my feelings are towards things, to statements being made and if I’m unhappy about something and the people I think are important to the project don’t give a damn - well what can I do?

Please, do what you want with the protocol stuff, I’ll stay out of the way and do something else, directly or indirectly related to diaspora. The-Federation.info expires in December - I’ll decide by then if it is worth to keep the domain or not…

36

What does “support officially” even mean if Friendica and Redmatrix are the ones supporting Diaspora? That wouldn’t even be possible. I don’t even know what that would mean and I certainly haven’t requested it or seen anyone else request it.

With “support officially” I mean that after we have a well-defined protocol, we can support this protocol, so that we can guarantee that the federation with third-party-networks doesn’t break.

Take NodeInfo for example, again. Jonne writes the spec for it and asks me to pass it on. I pass it on at some point afaicr, but didn’t have any immediate concerns with it. Later, we agree that it is time to implement it. Then when people actually give feedback, it is too late and not welcome.

Jonne waited 8 Months for feedback, and nothing came. Then he released the 1.0 Version, and THEN the feedback came … I can understand him. BUT he has taken the feedback and added it to the already released 1.0 version. It was OK, because nobody already used the 1.0 release (only diaspora), but normally you can not change something that is released. So it is correct, it was “too late”. But it was not “not welcome”.

I don’t really see your problem. NodeInfo and the try to create a stable well-defined protocol goes towards “The Federation” not away from it.

37

Great, I like the “everybody”! Why did you disagree on the vote then?

I’m pretty sure most people disagreed because of

Do not merge in changes before listening to all the stakeholders and noting their concerns with implementation and timetable

No one here disagrees with informing others about breaking changes.

38

I find it great that changing a button style or placement in the UI requires an ok from just about everyone but asking people for opinion on changing the heart of diaspora and the federation is “too much effort”. The proposal doesnt say “wait 8 months”. Jonne wanted to wait 8 months before merging NodeInfo in - I never understood why he started blaming me for what happened then.

39

You know what? Maybe you guys are not even the know everything re improving the federation code? Maybe, just maybe, code review could help? Except if you dont have any respect for the other parties, which I fear is partly the case here.

40

I find it great that changing a button style or placement in the UI requires an ok from just about everyone but asking people for opinion on changing the heart of diaspora and the federation is “too much effort”. The proposal doesnt say “wait 8 months”. Jonne wanted to wait 8 months before merging NodeInfo in - I never understood why he started blaming me for what happened then.

That is not correct: a UI change doesn’t need the OK from everyone. BUT everyone is welcome to give feedback, and if needed, a loomio thread is created. The same applies to the federation gem, EVERYONE is welcome to give feedback, and some people already have done this, and I respected their feedback. But I can not wait until everyone agrees with every little commit. The proposal doesn’t say “wait 8 months”, it says “Do not merge in changes before listening to all the stakeholders” with no time limit, this can even be longer than 8 months? The only thing I have “changed” (it is still backward compatible, so nothing really changed yet) so far is #2440, this issue is open for almost 4 years, do you think I need to wait longer?

Sorry, I don’t understand the second comment, who should review which code?