@julian I like the general direction, and it is very promising. Liking too the collab between NodeBB, Discourse and Lemmy in this regard. Very important that for interop sake. Thank you for all your efforts on the forum taskforce!
Posts
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead. -
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.@steve @naturzukunft @skyfaller @hugh @bob
@evanGood thread!
I wanna collect C2S compliant projects here: https://codeberg.org/fediverse/delightful-fediverse-apps/issues/130I'm planning updates to the 4 fedi-related https://delightful.club lists and reorganising them. Have a humongous maintenance backlog too.
In this reorg I want to highlight the more interesting, unexplored and innovative directions that our fediverse may be evolving to.
The other day I had discussion on 2 top categories for fedi apps list: https://thoresson.social/@anders/114433900582811705
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.Yes, that is already a huge improvement. And such phrases help align minds and thinking to explore what that should mean in practice.
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.Anyway, at this point I may make a cross-reference to old notes I made wrt major challenges we face, and still do today.
https://discuss.coding.social/t/major-challenges-for-the-fediverse/67
I think we can only hope to address these challenges if we do much more than just care for our code and protect our users. I understand where you come from and underline your ethics and values. We are kindred spirits in the commons But I am arguing that we may benefit from a slight perspective shift to help reimagine social.
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.I often mention this 'peopleverse' as something to envision, a hypothetical place where our offline and online worlds seamlessly connect and support our daily lives.
It is a philosophical abstraction, but it is a useful one. What happens when I open my eyes in the morning and events starts flowing in on the single timeline of the life that I lead?
(One thing is that I can go online and engage in global-square twitter 2.0 where people build protection after the fact.)
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.More interesting angle to your question, maybe why asked, is to "reimagine forums" in our new age of social networking.
Yesterday I had a discussion about https://blocks.githubnext.com "Reimagine repositories". Great ideation starting point. What is a repository actually? Container of a solution? Or .. what?
Maybe a forum is single-person software, attached to the social graph of the social web? Tapping into activity streams and knowledge bases. To 'slice' our personalized community views?
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.I am only observing that there is a missing focus on the social side, the soft and fluffy parts that many devs hate. And in return what we build is kind of a technosphere, missing the social layers to really click with people. Unless with the help of some 'digital transformation' which is the opposite of what we should be doing.. bring tech to be supportive of people, anticipate their true needs.
Anyway, I'm side-stepping. You know this well, and do wonders wrt help!
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.Yes, we must be responsible, create safe spaces, etc. Yet how we talk with or about other people matters a lot. There's endless debate around developer privilege, sometimes fair, sometimes not. But there is a lot of 'we know what is best for the user' explicit/implicit outcome.
If we are so diverse, why not walk that adventure together, discuss needs beyond the tech circle?
An analogy is development aid, where the West knows best what help to give.. they think.
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.Write software for online spaces where people can be safe!
Though I have a slight issue with 'users', and feel that with that terminology you already lose the first round, esp. in social networking.
https://social.coop/@smallcircles/114398657997240357
"The farmer protects the hens against the fox by building a fence around them". A single word puts so much distance between people.
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead. -
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.And a deeper discussion is that there really is no "the fedi", or they shouldn't be that notion for our future of social networking. Unless you want to refer to some broad category. I see 'fediverse' the same as internet and web, category names.
What do we want to DO on this fedi of ours? What needs do we have wrt communications online?
Microblogging certainly nice, I am doing it right now. But is shouldn't be the only hammer and everything nails. Enfin, you know the discussion
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.To get things on a forum archive in the right place, I'd have to mention that place in my mastodon toot. And then the next place too, unless they happen to be cross-federated with the other one.
One thing we discussed in the path was Unbound Groups brought in a FEP by Diogo of GNU Social, whereby the groups aren't bound to a single server instance where they are defined as an actor. This might help give the same community belonging that is more stimulating for collaborative actions.
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.@julian imho..
Pros and cons of decentralization + current state of fedi as a microblogging dominant thing.
We're on a fragmentiverse,where community waters down, what you send today is lost in history tomorrow. There is no search, no archive.
We are on a good path but the kind of organization we need to mature social web open standards and enabling technologies is not well supported on fedi.
Barrier to sign up to a single forum removed, easier access, but dispersal of the community efforts.
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.@strypey @skyfaller @hugh @bob
> SocialCG
Certainly. And SocialHub with the FEP process. And countless other parties where people give their utmost to improve things. Very valiant efforts.
However there are 2 realities on fedi. One the near stalled (for 6 years!) open standards evolution. And the other where people implement new stuff that introduces protocol decay and tech debt. This increases 'whack-a-mole driven development' that's counter to and detrimental for broad interoperability.
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.@hugh @strypey @skyfaller @bob
There's renewed interest in C2S and it makes sense wrt current tech trends (local-first, p2p). Can be very useful if you kept a log of your adventures and observations to stimulate others. Would be great to have fresh discussions on SocialHub (where various categories are also federated via the Discourse AP plugin).
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.@strypey @skyfaller @hugh @bob
I did not mention a #SocialHub thread. There are multiple discussions where various aspects were discussed, that might still be useful. The search facility is best way to find them.
As for AndStatus the github issue lists their step-by-step progress in investigating what was needed, and what the challenges were. One of them was unavailibility of appropriate server back-ends to test against, mentioned *at the time* as challenge.
Would
️ more #ActivityPub C2S dev.
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.Thanks for writing this article! I tooted about it:
https://social.coop/@smallcircles/114419670153108301
And it was good opportunity to follow-up on two #SocialHub threads relating to your examples in "The Bad":
https://socialhub.activitypub.rocks/t/exposing-edit-history-via-activitystreams/2930
https://socialhub.activitypub.rocks/t/update-note-quirk/4545/14
https://socialhub.activitypub.rocks/t/distinguish-between-posts-and-direct-messages/2283
-
As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.Also #SocialHub #ActivityPub developer forum has a bunch of C2S-related topic. You can use the forum search facility.
https://socialhub.activitypub.rocks
A very detailed investigation on what is needed client-side can be found in the #AndStatus project. It was never completed AFAIK as there were among others no server implementations to test against.