supports Groups. I'm wondering if anyone has developed something like a mailing list for AP yet?

I want to have a technical group ala a mailing list.

Anyone know of anything like this yet?

· · Web · 4 · 9 · 9


Not yet, but soon. As in later this year

I'll have group actors in Sputnik Opphuichi and message routing with envelope rewriting in the queue software

Compatibility with current services is the difficult part. Sending and receiving messages isn't a problem, but Mastodon and Pleroma users won't be able to manage their subscriptions in ActivityPub. They'll need a fallback in the form of a web interface or Majordomo commands


Very exciting.

re: Compatibility- Are you planning on a new vocabulary so that "subscribe" and "unsubscribe" are new verbs?

Anyway I'd love to learn more.

My opinion on ActivityPub extensions is that ActivityPub C2S is Turing Complete and therefore sufficiently expressive for any computation, so the best way to add functionality in the ActivityPub ecosystem would be to promote end to end ActivityPub, implement new features with existing vocabulary, and publish extensions to make implementation easier once the feature is mature

Some distribution patterns can be implemented with Follow*, but other patterns and administration will require additional Collections

Add and Delete will work with a Subscriber Collection just add well as a Subscribe Activity would

I should do an architecture document. There are a lot of expectations inherited from mailing lists and I think it's important to reproduce the desirable features and incorporate the lessons from 30+ years of email history


> #ActivityPub supports Groups. I’m wondering if anyone has developed something like a mailing list for AP yet?

Yes, they do. I would rather say, they developed exactly a mailing list, which just like the original does not require any special support from the protocol: you just CC it — and a bot behind it reposts the message to all the list subscribers.

Here it is: @rf — managed by @drequivalent.

> I want to have a technical group ala a mailing list.

May I try to dissuade you from doing it? Do not divide the community, let this #fediverse, so far as those who created it, decided to make it an illustration to #XKCD927 [1], remain a place for posting anime girls, and leave technical talks where they belong to: in full-fledged #mailinglists / #newsgroups.


No. We need proper groups. Not on Mastodon, but in Fediverse. Ideally, a separate engine that only does groups. No need to implement it in Mastodon or Pleroma. Keep things separated.

I once tried to inspire some folks to make it (because I don't have time to do it myself because work and also I gotta sleep sometime) but the project has gone dead I don't care who does it at this point.
@emacsen @rf

I know this discussion is old now, but ...

I agree with @drequivalent that we need proper groups in the #fediverse. But ...

> No need to implement it in Mastodon or Pleroma. Keep things separated.

They need to be able to at least follow and reply. Groups can benefit from specialized UI, like what #PeerTube offers for videos, or #FunkWhale for music. But would those projects be better if you couldn't follow channels or comment on videos from microblog accounts?
@z @hirojin @yaaps @Melezh

The nature of the protocol is that servers should not need to implement a feature locally to interact with it remotely. A service that only implements person actors can still follow and otherwise interact with groups and other actor types on remotes, at least on the protocol level. (Whether the front end stays out of the way is another issue)
@drequivalent @z @hirojin @Melezh

@yaaps sure, but I read the post by @drequivalent as saying that Mastodon and Pleroma ought not to support the groups feature. Perhaps that was a misread on my part, and the actual intend of that post was that the microblogs ought not to add complex UI for threaded group discussions (beyond improving what they already have perhaps).
@z @hirojin @Melezh

@drequivalent there are already a number of projects working on specialized UI for navigating groups and threaded conversations, federated over AP. The Reddit-a-likes like @prismo , #Lemmy ( @LemmyDev ), ( @mariusor ), #lobsters, #Guppe ( @datatitian ), #MoonTree , and #Pantheon. Friendica and Hubzilla also have groups that could be federated over AP, although I don't think they are yet.

@z @hirojin @yaaps @Melezh

@liaizon @strypey @drequivalent @prismo @LemmyDev @mariusor @datatitian @z @hirojin @yaaps @Melezh @grishka

Yeah, there are going to be full-blown groups with at least walls and forums, just like there are in VK. Events will be a specialized kind of group. I'm thinking about how to best represent that in AP, seems like making it a Group with an Event in attachments is the best way.

@grishka @strypey @drequivalent @prismo @LemmyDev @mariusor @datatitian @z @hirojin @yaaps @Melezh @grishka

have you thought about how membership in your groups will work with accounts outside of your platform? Like will I (as a user on a mastodon instance) be able to join a smithereen group from this account?

@liaizon @strypey @drequivalent @prismo @LemmyDev @mariusor @datatitian @z @hirojin @yaaps @Melezh @grishka

This is an interesting question. Using the Join activity to join groups makes sense and that's what the spec suggests. I'll probably also be accepting Follow for compatibility purposes. But what happens after you do join it... How would you post there for example? There are going to be way too many concepts and actions unknown to Mastodon and other microblogging software.

There's a lot of prior art (and cruft) in email distribution lists. ActivityPub doesn't define group or organization actors functionally or semantically, but I think the heavy, feature rich, implementations that mimic Mailman will come when the community starts talking about organizations and that groups will mostly be lightweight like @GuppeGroups

There's no necessity for implementations to be uniform, however, and Mastodon compatibility (while nice for Mastodon users) isn't a necessity for being part of the fediverse

To succeed as its own thing (rather than as a collection of software that is like some other social network, but federated), we'll need to break the habit of using microblogging to drive traffic to content that we host. New services need to use progressive enhancement to share content over ActivityPub that displays in clients with best effort, because failing to do so will continue to reinforce publisher centered content distribution patterns that lead to capture by capital
@liaizon @strypey @drequivalent @prismo @LemmyDev @mariusor @datatitian @z @hirojin @Melezh

@yaaps @grishka @guppegroups @liaizon @strypey @drequivalent @prismo @LemmyDev @mariusor @datatitian @z @hirojin @Melezh On your last paragraph: valuable, long-lived, "slow" content is organized as chapters, articles or documents arranged in blogs, books etc. This is unrelated to centralized publishing and capital accumulation. Micro-blogging can be used for conversations and comments about “slow” content. Latter can be progressively presented in ActivityPub clients using previews and ogp meta.

Either the recipients cover the costs of storage and distribution or the publisher does. If the publisher does, then they need to recover their costs. There's no way that does not result in the vast majority of content serving the interests of capital with the bulk of the remainder uncritically reflecting privilege as a consequence of relying on donor funding to scale

@emacsen Osada had basic support for groups when it was still being developed, but the project is dead now.

Other than that, only #fediquest plans to support question/answer sharing for groups, but that project is still in very early stages.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!