Beady Belle FanchannelNew post: Can we have a more “social” media?
https://profpatsch.de/essays/a-more-social-media
On advertising, the Fediverse, and what a more human social web could look like.
Special mentions: @smallcircles, @phnt, @happy-programming
ADVERTISERS ARE NOT OUR MASTERS
SCALING IS NOT OUR DOGMA
SCALING IS NOT OUR DOGMA
midzer@Profpatsch Nice read :)
For me, current web is too *fast* also. Lacking "real" communication and dialogue, even on the fediverse.
I am lurking in forums and real-time-chat channels on IRC/XMPP way more often now.
🫧 socialcoding..Great article @Profpatsch and thank you for mentioning my article. Social experience design uses the notion of Personal social networking to think about solution design and social network evolution, which considers offline social contexts and societal constructs we are familiar with. The online world becomes an extension to that.
For that first step I think of Actors as providing Services and acting *on behalf of* people. Services can be composed, orchestrated, and choreographed to deliver social experiences that satisfy people's needs.
An Actor has an identity, but it is not tied to an account or even a person. How they relate is solution-specific. Hashtags too are solution-specific. But standardized reusable building blocks can be used in interoperable message exchanges.
Microblogging as is implemented now is app-centric and represents standing on a soapbox at Trafalgar Square as your default mode of comms. Service-oriented social web may have topical Discussion services.
@Profpatsch Furthermore, it's called #ActivityPub, but if the only "activity" or "activism" (I feel) is to read, click/like/boost and therefore consume, I cannot realize a *social* aspect as well.
Yes, from time to time there might be a communication exchange. After all, we're all sitting at home alone instead of gathering together to celebrate "the end of the world" or whatever...
wakest likes your bugs ⁂@Profpatsch oh cool what did you build @happy-programming with?
@liaizon Right now it’s two golang files that do a half-assed job at implementing activitypub
@Profpatsch ah very cool its custom! have you published the code? I would add it to a list of implementations I help manage at https://delightful.club
@liaizon yeah, it’s published, but currently I’d not feel comfortable being listed anywhere, the code is really rough and I haven’t really made sure it’s free of security issues
@Profpatsch honestly seeing it running live and followable I would say you are better off then half the things listed on these lists
@liaizon Haha, that might be true. I did link it in the post, right now it lives at https://codeberg.org/Profpatsch/Profpatsch/src/branch/canon/users/Profpatsch/booster-bot and https://codeberg.org/Profpatsch/Profpatsch/src/branch/canon/users/Profpatsch/activitypub-go
Delightful lists are friendly lists. I started Delightful commons in reaction to the popular Github Awesome project by Sindre Sorhus where many lists feature proprietary products, not FOSS value-aligned. Delightful lists are purely for FOSS, open science, and open data related resources.
Something can be delightful well before it is awesome. It is delightful that people provide the fruits of their work for others to benefit too.
Especially relating to the 3 fediverse lists delightful is defined as "any project with the *intent* to join the fediverse ecosystem".
This aligns with Social experience design, which considers a Solution to exist as soon as you can write it on a sticky note (see example). From there it evolves.
> I would add it to a list [..] I help manage at delightful.club
Thank you@[email protected] !
Note that the new location is at https://delightful.coding.social (the old domain was kindly provided by, and works as long as @yarmo keeps the subscription going).
@liaizon fwiw I made & deployed some security improvements, the current security mechanisms are documented in https://codeberg.org/Profpatsch/Profpatsch/src/commit/249aa389a2023814b328af8fc795750fd28d995d/users/Profpatsch/activitypub-go/security.md
maybe @silverpill wants to take a look at whether this all sounds sensible?
@liaizon @silverpill I want to write a blog post on this at one point, but I don’t know if I missed anything or misunderstand things.
silverpill2. Activity-Level Origin Checks
Same-origin is checked rather than exact equality so that servers with multiple actors can sign on behalf of any of their actors — a common legitimate pattern.
For incoming activities, consider checking exact equality. See FEP-fe34, section "Signatures":
In order to minimize damage in the event of a key compromise or insufficient validation, consumers MUST verify that the signing key has the same owner as the signed object. Consumers MUST also confirm the ownership of the key by verifying a reciprocal claim.
This is not strictly necessary, but would help if the origin server does poor job at validating user input.
3. Embedded Object Origin Checks
Owner origin: the object's owner (actor for Activity subtypes, attributedTo for Notes/Objects) must be same-origin as the signing actor. Anonymous objects (no owner field) are accepted.
In this case I also recommend checking owner ID equality, as a rule of thumb. Because origin servers implementing C2S API may fail to validate all embedded objects (which can be deeply nested).
Response body size limits
You may also need to limit the number of redirects and set a timeout. Some HTTP libraries have bad defaults.
By the way, I collect such recommendations in this guide: https://codeberg.org/ap-next/ap-next/src/branch/main/guide.md#network. Contributions are welcome!
@silverpill @liaizon I’d say we should rewrite these standards to have a “here’s how an ideal world would look like” and then “here’s what you might want to do for compatibility with existing implementations” approach, instead of that horrible MUST/MAY/SHOULD trainwreck.
e.g. ideal world: “host and scheme should be lower case”, compat work: “you can lowercase them before comparison, but do it like this: <instructions>”
@silverpill @liaizon not dunking on your work ofc, but I think the “best practices” around writing standards are just not very good unfortunately
@silverpill @liaizon Like, even just using urlparse() from different languages exposes us to implementation difference issues, so a simple split("#")[0] equality is *way* better than urlparse & field comparison for security reasons.
which means lowercasing is a bad-bad!
@silverpill @liaizon What does this mean? “Follow redirects, but set a limit. Request must be re-signed after every redirect.”
do you mean I have to check the new http signature on every 30x response? I don’t believe that can work??
@Profpatsch You need to create a new signature because the request target is changing. It is a part of a signature base, so the initial signature becomes invalid when the client follows a redirect.
@silverpill @liaizon Another issue I noticed: “set a max request/response size” means that we are essentially forced to implement paging of outboxes both on client and server
@silverpill @liaizon we should also definitely provide some actual values here, otherwise it’s pretty useless tbh …
@Profpatsch @liaizon The guide recommends limiting the response size, to prevent DoS.
I also found this in your SECURITY.md:
@silverpill @liaizon yeah, but in essence anything that produces or consumes an outbox needs to implement paging because of that.
@Profpatsch @smallcircles @phnt
What hasn’t been considered is the ability of multiple people to speak with “one voice” yet.
Imageboards?
There was one that federated using ActivityPub: https://github.com/FChannel0/FChannel-Server
@silverpill @smallcircles @phnt uh, I want to stay away from image boards as far as possible, they are the opposite of healthy communities. I have no clue how my post made you think “probably image boards” lol, did I not use the word “human” enough