Hello @evan and @bifurcation .. a question.

For inclusion of #ActivityPub information resources on the delightful-fediverse-development curated list there is this (now expired) #IETF draft exploring #MIMI / #MLS versus AP. I find this draft to be well-written and informative, and thus the draft possibly a candidate for inclusion for people as additional background reading to the #SocialCG work on MLS. Unless there are so many changes since the creation of the draft that it may raise confusion, and should not be included. What is your opinion here?

https://ietf-wg-mimi.github.io/mimi-arch/draft-ietf-mimi-arch.html

@Varpie @box464 @ivan

If you look at https://forgefed.org it chose to implement as:Offer in the context of "software development" toplevel domain (or perhaps "code forges" application domain).

Here we may say that it is alright to do so, if its use adheres the informatively specified functionality of "offering one object to another" in that general sense.

Yet I think I'd model this quite differently, and mapping to ActivityStreams is more a disadvantage than anything else. The spec has to describe the combinatorial logic of what to do when receiving as:Offer and needs a 'smart pre-processor' to determine the use case and bounded context.

@Varpie @box464 @ivan

To just name a well-known existing eCommerce vocabulary: GoodRelations.

http://wiki.goodrelations-vocabulary.org/Cookbook/

Not saying it is appropriate, or the only choice, but just as example. Here you'd have a gr:Offering instead of an as:Offer to indicate "something available for purchase (or bartering)". And there are a bunch of constructs to model payment, delivery methods, etc.

Avoiding the very generic as:Offer has the advantage you convey proper meaning, and don't get to deal with "whack-a-mole" development where you have to adapt your internal business logic to all the overloaded uses some app developer put on the fediverse wire for their own custom as:Offer interpretation

@steve @silverpill

Btw @HolosSocial I really love the clean documentation style of your "How it works" page, to outline various use cases. Great work!

https://discover.holos.social/how-it-works

@steve @silverpill

Yes good to mention, I was out of chars. It becomes I guess like a local-first S2S on the client-side, tied to compliant Relay servers that facilitate the tunnel.

Perhaps @HolosSocial can enlighten us for their project, but such a set up should not necessarily bind to a single client.

@Varpie @box464 @ivan

Btw, I added #OfferBots at the end, a (halted) project by Andrew Mackie, that has a very interesting concept for the #ActivityPub fedi. The website describes *very well* the problem with "aggregators" to be addressed, but the solution section of the website is not up to par. It was stopped right at the time when Andrew became aware of the fediverse.

Discussed here on #SocialHub:

https://socialhub.activitypub.rocks/t/offers-unchained-federated-offerbots/697

@Varpie @box464 @ivan

Yes. Depending on what you want I'd follow a more design-first approach of the particular domain you want to model. And not shy away from custom types, or better, an existing domain-specific vocab.

On the fediverse there's this urge to try to cram and map any functionality on the poor #ActivityStreams vocabulary, which only has a small number of 'social networking primitives' to work with. The use case section in the spec at par. 5.8.12 states that Offer involves "offering one object to another" which is a very low-level technical ability, more indicating of a protocol capability than for general use as "business domain".

https://www.w3.org/TR/activitystreams-vocabulary/#motivations

In your last scenario "Bidding" seems to indicate the business domain / bounded context, part of perhaps a larger eCommerce toplevel domain. You might use https://eventmodeling.org

Also: who is the actor? You may have an Offer service, and "OfferService announces Alice's offer".

Interesting too: https://offerbots.org/the-problem/

@steve @jerger

Yes, I would highly discourage the use of "app". It is why I scare quoted it, but "app" is common language when people talk about the fediverse. "App" is a neat container concept that fits the full scope of ones own FOSS project, but on the fediverse - a growing heterogeneous and interoperable social network - one becomes highly dependent on the foundational network communication layer based on #ActivityPub, and any fedi FOSS developer should be concerned beyond direct project scope, and pay attention that this foundation evolves healthily. This unfortunately happens unsufficiently, and only a very small number of people try to get the ecosystem as a whole to higher levels, volunteering time where it does not directly benefit their own projects. Think @silverpill for the #FEP and @evan for #SocialCG.

Cool find yesterday was that @HolosSocial rather than C2S has a "full AP server" client-side, that communicates with a Websockets tunnel to a dedicated relay server.

@jerger @steve

Keeping msgs immutable is a general best-practice, I gather.

In the case you mention it becomes confusing to still use client/server terminology. You have a full actor on the client's side, and when it sends a msg it acts in server/S2S role.

Btw, in that scenario we do not have to make the distinction client + server anymore, as we have just actors communicating with each other. Then we can think in terms of the actor model, and honor its qualities.

A client sending to the server's outbox is then analogous to an actor sending to another actor's inbox. That is a one-way msg exchange usually, fire and forget (esp. in a pure event-driven architecture... which the current fediverse is not). The remote actor is not responsible for keeping the Activity (event) in its server-outbox / actor.inbox. That corresponds to the spec part "may disappear at any moment".

@fedicat @reiver

(My opinion is that AI as introduced today constitutes inhumane technology, that serves to prolong hypercapitalism and the status quo of ever increasing wealth inequality. It is dangerous technology in how it disempowers people who come to rely on the technology, while it is wholly owned by all-powerful Big Tech megacorporations and their billionaire owner class.)

@fedicat @reiver

Unserious #ThoughtProvoker of sorts..

How about letting #AI - guided along by some protocol experts to formulate good prompts - maintain and evolve the open standard specs based on all the info the AI has sucked up from all the FOSS projects that are implementing #ActivityPub.

(Note that I am wary of AI for a whole host of reasons, mostly all relating to its disruptive introduction and its potential dehumanising effect, eroding social cohesion and connection between people.)

@fedicat @reiver

(Interesting.. just saw the vote count on the poll go from 10 to 9 and adjust results)

@fedicat @reiver

When it comes to fediverse there are roughly 2 crowds. One who thinks fedi is ready for scale and should be growth-hacked asap to offer alternatives and safe refuge to the masses of people locked into corporate social media walled gardens.

And a group who thinks this rapid upscaling is not yet possible without the fediverse suffering a hostile corporate takeover, and enshittification process.

AI finally makes fedi rapidly accessible for newcomer devs, but increases that risk.

@liaizon @julian @phanpy

It is simply a 404 not found of the image, looks like, checking in Mastodon web UI.