Post 2766888 by hankg@mastodon.technology
(DIR) More posts by hankg@mastodon.technology
(DIR) Post #2718176 by sean@social.deadsuperhero.com
2019-01-06T23:37:27.325519Z
0 likes, 1 repeats
The stance by some of the #Diaspora core devs over #ActivityPub is quite honestly disappointing, and kind of perpetuates everything that depresses me over that project.https://github.com/diaspora/diaspora/issues/7422There are many valid criticisms to be had, but Diaspora in general has done fuck-all to support federation with other platforms, forcing those systems to conform to its own protocol instead. The do-nothing attitude of their devs is particularly infuriating because their pushback arguments fall flat when compared against other projects. Friendica put the effort in, as did Hubzilla and Osada. None of them have "perfect" implementations by any means, but people within those projects have nevertheless made some kind of effort.
(DIR) Post #2718353 by sean@social.deadsuperhero.com
2019-01-06T23:42:24.803348Z
1 likes, 0 repeats
At this point, I'd rather just see a Diaspora frontend for #Pleroma come out, and have everyone from D* migrate over to it. At the very least, people on that end of the Free Network could actually plug in to the full benefits of the fediverse, rather than linger in the corner of the Free Network that was really just formed out of apathy on Diaspora's part. Literally all of the platforms in that part of the graph other than Diaspora support a secondary fediverse protocol anyway.
(DIR) Post #2718384 by orekix@pl.smuglo.li
2019-01-06T23:43:17.988475Z
1 likes, 0 repeats
@sean isn't Friendica a better alternative for that type of social network?
(DIR) Post #2719074 by kaniini@pleroma.site
2019-01-06T23:46:16.612810Z
1 likes, 0 repeats
@sean those use cases are essentially what the MicroFE project is about. we intend to take the prototype that dansup made and enhance it for those usecases. but there's some things we need to settle outside of the scope for Pleroma 1 release cycle to really make this a workable reality (like full aspects support instead of *just* lists).
(DIR) Post #2719081 by kaniini@pleroma.site
2019-01-06T23:51:02.681194Z
1 likes, 0 repeats
@sean (and to support diaspora privacy usecases, we need to also move native pleroma-pleroma federation (well, friendica too because they agree with a lot of the changes we propose to AP) to the more OCAP-style model I have been talking about.)
(DIR) Post #2719090 by MirceaKitsune@mastodon.social
2019-01-07T00:00:28Z
1 likes, 0 repeats
@sean I believe that sort of attitude is harming the initiative of increasing connectivity over decentralized platforms. It's sad when someone shares the same vision as you, yet you can't agree because they have a different view of implementing it and they just won't see certain things.
(DIR) Post #2719097 by rysiek@mastodon.social
2019-01-07T00:04:47Z
1 likes, 0 repeats
@sean it's really depressing but hardly surprising. Diaspora devs have acted like that for as long as I can remember.They got to be the biggest federated social network a while back and started being dicks about it. This, sadly, continues.One of the reasons I don't log in to my Diaspora account anymore.
(DIR) Post #2719182 by clacke@libranet.de
2019-01-07T00:08:06Z
1 likes, 0 repeats
Meh. If Diaspora core believes that mapping Diaspora and AP onto the same software is impossible by design and that connecting to a million users is "sacrificing UX for purely ideological reasons", then I guess we'll just use Friendica, GangGo or HubZilla, all of which already solved the problem of talking to both AP and Diaspora.
(DIR) Post #2719770 by kaniini@pleroma.site
2019-01-07T00:14:23.815895Z
1 likes, 0 repeats
@orekix @sean Pleroma BE supports any type of social network. Feather, for example, is a frontend that implements a facebook/diaspora-like experience. It was a proof of concept, but still live at https://feather.pleroma.site/
(DIR) Post #2719775 by rigelk@miaou.drycat.fr
2019-01-07T00:12:17Z
2 likes, 0 repeats
@sean I've read too much of their issue/discourse threads to care about D* anymore.On a good note, #Friendica devs are nice, and Friendica looks nice. I had the chance to meet one of their devs at #35c3 and am keeping an eye on the project now.
(DIR) Post #2719794 by craigmaloney@octodon.social
2019-01-07T00:07:45Z
1 likes, 0 repeats
@sean this isn't sitting considering how lackluster the blocking is on D*, and how "if it doesn't fit the D* model then it is broken" mentality.
(DIR) Post #2719799 by starbreaker@pleroma.site
2019-01-07T00:06:13.060651Z
1 likes, 0 repeats
@rysiek @sean It didn't help that they acted like the influx of Google+ refugees via pluspora.com were going to gentrify their federation or something.
(DIR) Post #2719899 by kaniini@pleroma.site
2019-01-07T00:29:32.265595Z
3 likes, 0 repeats
@sean i'm not really a huge advocate for ActivityPub anymore.the specification is a mess, the authors did not consider trust and safety as design goals.are there good things in AP? absolutely.but we're a year into having implemented AP in Pleroma, and two years into building Pleroma with an AP-like AS2 internal representation.based on direct experiences and talking with other devs about their thoughts and experiences building Pleroma, there are some conclusions.there are some good conclusions:* ActivityPub is a decent enough transport protocol* AS2 is a decent enough internal representation when combined with some elements of AP* the core semantics of ActivityPub are mostly obvious and understandablebut there are many bad conclusions too:* ActivityPub itself is woefully underspecified* there was very little thought into trust & safety concerns, the protocol is based on signatures as source of truth instead of capabilities* it is impossible to follow the ActivityPub spec completely to the letter and have a working implementation* ActivityPub ratification process was largely driven by a single vendor's feedback (Mastodon)* ActivityPub development process invited recognized experts and mostly ignored their suggestions, for example signatures as source of truth is a direct consequence of ignoring these concernsI need to blog more about this, but ActivityPub is the "worse is better" of social protocols.
(DIR) Post #2720293 by kaniini@pleroma.site
2019-01-07T00:35:37.506767Z
1 likes, 0 repeats
@sean but the thing that *really* pisses me off about ActivityPub is this: we *knew* that OStatus was a flaming pile of shit when it came to security.ActivityPub made some significant improvements, but it is still a very insecure protocol. it mostly gets the job done, but when it comes to doing so in a way that protects your safety, and in a way you can trust, it absolutely fails.almost all of the discourse where Pleroma is blamed for something is actually just Pleroma refusing to cover up yet another failure of the ActivityPub standard.this is not to say that we should revert AP and return to OStatus -- absolutely not, but we must do better.
(DIR) Post #2720572 by moggers87@mastodon.xyz
2019-01-07T00:54:14Z
0 likes, 0 repeats
@sean I don't understand the comment about D* rewriting its own fedi protocol - it seems to imply that AP was a big secret that came out of nowhere. Am I reading that wrong?
(DIR) Post #2720573 by sean@social.deadsuperhero.com
2019-01-07T01:00:25.518657Z
1 likes, 0 repeats
@moggers87 nah, it was a timing thing. AP was in the process of being finished up as a first draft around the same time that Diaspora was in the process of finishing their own protocol rewrite.Tons of effort went in on Diaspora's end to fix up their own stuff, and so the proposal of using a different protocol left a bad taste in the mouths of some Diaspora developers.
(DIR) Post #2720637 by alexl@mstdn.io
2019-01-07T00:59:36Z
0 likes, 0 repeats
@sean but also Mastodon does so with ActivityPub client-server protocol that should be implemented by Mastodon with it acting both as server and as a client to unlock nomadic identities and other thinghs
(DIR) Post #2720638 by sean@social.deadsuperhero.com
2019-01-07T01:02:58.782078Z
0 likes, 0 repeats
@alexl yes, but at present virtually no one supports c2s. Some effort is going in on Pleroma's end now, but no one is quite sure what the positive outcomes of unilaterally supporting it will be. This is also because the use-cases and behavior for c2s are not particularly well-defined yet.
(DIR) Post #2722968 by wakest@mastodon.social
2019-01-07T02:45:07Z
1 likes, 0 repeats
@rysiek @sean wow that thread got heated.
(DIR) Post #2726288 by lorabe@mastodon.cloud
2019-01-07T04:14:42Z
1 likes, 0 repeats
@sean Well, nowadays i don't feel the need to have a Diaspora account to access a free and ethic internet culture. Mastodon has done a lot to build a social federated platform and then came other amazing projects.My opinion is These are drowning kicks.
(DIR) Post #2729768 by rysiek@mastodon.social
2019-01-07T08:51:19Z
1 likes, 0 repeats
@wakest @sean yeah, I do feel strongly about this, mainly because federated social networks are at a disadvantage due to the Network Effect; splitting the field further makes this problem exponentially worse.So, D* refusing to implement *any* other protocol (they've been asked to implement a number of protocols and refused each and every time) is actively undermining the broader federated social networking.And the reason? Because Diaspora devs treat this as a protocol measuring contest.
(DIR) Post #2732391 by strypey@mastodon.nzoss.nz
2019-01-07T10:39:27Z
1 likes, 0 repeats
@sean maybe the solution is to come at the problem sideways and start talking to podmins about it? If a significant number of podmins were willing to move to an AP-compatible soft fork of Diaspora or install an AP plug-in, a team could be formed to do the create it. Then all podmins would have the option to connect to the #fediverse, regardless of what the #Diaspora devs themselves think about it.@kaniini @rysiek @craigmaloney @cj @starbreaker @wakest @clacke @rigelk @mike @moggers87 @alexl
(DIR) Post #2740226 by heluecht@pirati.ca
2019-01-07T16:42:29Z
0 likes, 0 repeats
Yeah, it is complicated. The big problem in Diaspora is that it isn't designed as a multi protocol application.Implementation of AP in Friendica was extremely easy. Since it had been designed as a multi protocol system from the start, all functionality is flexible enough and is encapsulated enough, so it can be called from the different protocol implementations. Additionally I have to thank the developers who implemented AP in Hubzilla (I guess it was Mike), since I had been able to use parts of their code or to have a good look, how they implemented stuff. So the HTTP signing and LD-signatures really had been done in less than a day.For Diaspora this possibly could be more complicated. Additionally AP needs threaded comments, which Diaspora supports in the core, but the frontend doesn't support it. (Same is valid for likes on comments). So implementing AP in Diaspora would also mean some significant work on the frontend side. So this is really a bunch of work.
(DIR) Post #2740228 by sean@social.deadsuperhero.com
2019-01-07T17:01:26.023684Z
0 likes, 0 repeats
@heluecht Agreed, but we did already encapsulate Diaspora's federation into a Ruby gem. Some preliminary work has already been done to make a secondary protocol feasible. Support for multiple protocols isn't totally out of the question.
(DIR) Post #2765960 by alexl@mstdn.io
2019-01-07T13:01:50Z
0 likes, 0 repeats
@strypey I used Diaspora for years and I even implemented a button on my blog to comment using Diaspora. But in 2019 it still doesn't have client API. In modern software implementing that kind of API is really easy. If Diaspora isn't capable to do that in many years I suppose its codebase is too old and I don't see why one should spend more time in it implementing AP federation or anything else.
(DIR) Post #2765961 by lightone@mastodon.xyz
2019-01-07T19:53:25Z
0 likes, 0 repeats
@alexl If you wait a little longer, you'll see what'll come out of @hankg work on diaspora's API: https://www.nequalsonelifestyle.com/2018/12/30/diaspora-api-blog-discussion-details
(DIR) Post #2765962 by hankg@mastodon.technology
2019-01-08T11:17:09Z
1 likes, 0 repeats
@lightone @alexl Thanks for the highlight! The API is feature complete and done primary development but still in late-stage development (reviews, tweaks, lots more real world testing, etc.) The devtest server is open for others to register on so they can play with the API at this time though. Feel free to ping me or drop onto the Diaspora Discourse Forum for help or to give feedback. https://discourse.diasporafoundation.org/
(DIR) Post #2766888 by hankg@mastodon.technology
2019-01-08T11:26:02Z
0 likes, 0 repeats
@sean The "have done nothing to support federation with other platforms" comment...is there something other than integrating with AP that would qualify for this? Is there an outreach problem with people using/implementing D*'s protocol, something else they could/should be doing, or is it really "just do AP"?
(DIR) Post #2766889 by sean@social.deadsuperhero.com
2019-01-08T12:10:17.015613Z
0 likes, 0 repeats
@hankg yes, nearly their entire history of interacting with other projects in the space. While Diaspora has openly praised efforts from other projects to support the Diaspora protocol, it has long done nothing to support those who have done so. That dates back all the way to the early days of Friendica, when the protocol itself was practically undocumented and had to be reverse-engineered.Things did improve slightly after the major overhaul of the protocol, as documentation for it got much better, to the point that new people wrote implementations and had dedicated community developers to ask questions to. So the Diaspora community did offer that.However, any proactive plans for interoperability from Diaspora's end were dismissed long ago. Diaspora was largely against adopting vanilla OStatus, apprehensive about Tent, and basically unresponsive about Zot. While other projects were more interested in interop, D* has historically been more interested in pursuing their own needs and interests.This would all be fine and dandy, if it weren't for the fact that this was a fairly popular recurring topic in the community, that of strengthening federation by having different platforms work together.
(DIR) Post #2766944 by cj@mastodon.technology
2019-01-07T12:16:18Z
0 likes, 0 repeats
@strypey Sounds like it might work. Unfortunately my focus is pretty narrow - implementing federated protocols as libraries for #golang implementations. Right now it's just AP, but I originally wanted to also be able to include a library for the Diaspora protocol, too.
(DIR) Post #2766945 by strypey@mastodon.nzoss.nz
2019-01-07T12:30:05Z
0 likes, 0 repeats
@cj have you looked at #GangGo? It's written in GoLang (thus the name). Initially it was designed to federate with Diaspora, but I'm told they've been working on implementing AP. Maybe you could share code, or even pool your efforts?https://git.feneas.org/ganggo
(DIR) Post #2766946 by hankg@mastodon.technology
2019-01-08T11:34:18Z
0 likes, 0 repeats
@heluecht @sean Thanks for providing the insight versus the whole "why don't they **just** do this or that..." There is a lot of emotion wrapped up in this whole AP discussion which seems to then devolve into shitposting.
(DIR) Post #2766947 by cj@mastodon.technology
2019-01-07T12:47:12Z
0 likes, 0 repeats
@strypey Do you know if any of their developers are on the AP Fediverse? It isn't clear how to reach out to them.
(DIR) Post #2766948 by heluecht@pirati.ca
2019-01-08T11:42:52Z
1 likes, 0 repeats
I prepared a blog post about AP as well. I will publish it in the next days.
(DIR) Post #2766949 by heluecht@pirati.ca
2019-01-07T16:31:29Z
0 likes, 0 repeats
You should be able to reach them on the Feneas channel on Matrix and IRC: feneas.org/contact/
(DIR) Post #2766951 by strypey@mastodon.nzoss.nz
2019-01-08T02:13:06Z
1 likes, 0 repeats
@heluecht thanks for the tip, it seems like @cj managed to get in touch with them:https://git.feneas.org/ganggo/federation/issues/17#note_4103
(DIR) Post #2826649 by adfeno@ecodigital.social
2019-01-10T08:41:05Z
0 likes, 0 repeats
@sean This is why I don't like non-standardized federation or its extensions (I mean that I dislike those which are not under #W3C, #ISO or #IETF or some standards foundation). The moment I saw myself managing two accounts for the same purpose, and one standardized and federated, I got out.
(DIR) Post #2826650 by sean@social.deadsuperhero.com
2019-01-10T08:44:05.729511Z
0 likes, 0 repeats
@adfeno I dunno, the presence of a standards body does not automatically mean that something is good. Just look at SAML š
(DIR) Post #2840283 by aemon@social.targaryen.house
2019-01-10T09:56:10Z
0 likes, 0 repeats
@sean So, actually 2 years later, did pump.io finally implement AP as Evan P. said there?
(DIR) Post #2840284 by sean@social.deadsuperhero.com
2019-01-10T18:20:53.115231Z
0 likes, 0 repeats
@aemon They're working on it, but still not there yet.I honestly don't understand that platform's developments. Thousands of commits, and it looks the same as it always has.
(DIR) Post #2843969 by heluecht@pirati.ca
2019-01-10T20:42:39Z
1 likes, 0 repeats
But what takes them so long? I just invested some weeks and was nearly done.
(DIR) Post #2843983 by sean@social.deadsuperhero.com
2019-01-10T20:44:59.710489Z
0 likes, 0 repeats
@heluecht @aemon It could just be that there's really only one guy working on it. Also, I'm not an expert, but the application structure looks like a mess.
(DIR) Post #2847927 by hankg@mastodon.technology
2019-01-10T21:29:57Z
0 likes, 0 repeats
@heluecht @sean for many of the larger changes its an FTE combined with necessary focus problem. As was written on that chain AP has other factors going on too. Blistering developer ranks is something Iām hoping to do directly and indirectly.
(DIR) Post #2847928 by hankg@mastodon.technology
2019-01-10T21:31:35Z
1 likes, 0 repeats
@heluecht @sean bolstering not blistering