Open drequivalent opened 6 years ago
I have been tinkering with the concept of an ActivityPub library or "engine" using Python with Celery (which would play the role Sidekiq does in Mastodon). I should revisit this work and perhaps see if it could be applied here.
I would like to get ActivityPub suppoet added, I've been hoping someone would come along who knew how to implement it!
Are you familiar with SocialHome? They are one of the federated social network apps using the Diaspora protocol, also developed in Python/ Django. Perhaps the developers of SocialHome and GetTogether could collaborate on figuring out what existing Python/ Django code there is for exchanging event data across federated networks using standardized protocols?
Both Friendi.ca and Hubzilla have events calendar features, and since they're close cousins, I'm guessing they've at least done some scoping work on federated exchange of events data across apps that could shine some light on possible solutions. NextCloud and ownCloud also have events calendars, and I believe the former (and possibly the latter) is implementing ActivityPub internally for federation between its own instances, so it might be worth talking to them as well.
Finally, Upcoming.org is another events site using a free code engine, and while I don't know if they have any interest in federation, it could be worth reaching out to them too.
Thanks @strypey for the ping, GetTogether looks awesome, will be keeping a look.
Regarding federation. I really recommend going with ActivityPub. It has good support for events in the standard vocab and supports extensions where support runs out and has recently picked up steam with many projects either implemented or planning to implement. It's the first federation protocol for the social web that is starting to feel like a standard, even though it's still early days.
For Socialhome (which has events planned in a more Facebook kind of way), ActivityPub support will arrive via my federation library, which currently supports Diaspora protocol. The idea is to have a library that supports multiple protocols over one unified API, so it's a bit opinionated, not a direct 1-1 mapping of the protocol. If interested to have a look, and maybe even collaborate, it's here. I plan to work on activitypub for the library within the spring / early summer, by current timetable.
Initial ActivityPub work is live here: https://gettogether.community/activity_pub/events.json
Can somebody please comment with what more needs to be done before closing this issue?
I'm not sure how to use this in the context of other sites. It only seems to be a large feed of all of the events, not something where each team / location can broadcast what's going in there.
@mhall119 you'll need to implement webfinger so other fediverse implementations can look up Actors (Person, Group, etc). It's not technically part of the spec, but most implementations require it.
When a user/team creates a new event, you'll need to put an Event object in the Actor's outbox, wrapped in a Create Activity.
It probably also wouldn't hurt to test against other ActivityPub players in the space. The main ones of importance with working implementations are:
Basically none of those support an Event activity specifically, but it should be possible to generate some kind of fallback note activity that each of these things can see.
@mhall119 would you mind if I took a stab at this? I'm not a "federation expert" but I think I can work this out given a bit of time. With a milestone of 1.0.0 I imagine I can get it done with lots of time for review.
Go for it! The two relevant specs are ActivityPub and ActivityStreams
There is some preliminary ActivityPub seriaizers in ./events/activity_pub/ that should serve as a starting point
OK, here is what I'm thinking for a 1.0.0 implementation. We'll probably want more levels of visibility for actions in a later update:
Actors:
- User
Inbox/Outbox stream of actions
Actions:
- Follow event
- Star/like event
- Comment on event
- Reply to comment on event
- React to comment on event
- Invite to event
- Accept invite
- Tentative Accept invite (Maybe)
- Reject invite
- Update for all of the above
- Remove for all of the above
- Block User
- Event
Inbox/Outbox stream of actions
Actions:
- Announce all user actions taken on event
- Team
Inbox/Outbox stream of actions
Actions:
- Announce all user actions taken in team
- Org
Inbox/Outbox stream of actions
Actions:
- Announce all user actions taken in org
- Place
Inbox/Outbox stream of actions
Actions:
- Announce all user actions taken in place
In effect, this would mean searchable endpoints for Events, Teams, Orgs, and Places. Each would have their own feed. Users can socially share events through comments, likes, and federated invites.
This will necessitate a few Model Changes as at least the current Attendee model will need to be decoupled from local users.
TODO:
@polymerwitch if you hit stumbling blocks, the best place to ask advice is the W3C #social IRC chatroom, see here for details. Good stuff :+1:
Thought this Python ActivityPub library might come in handy: https://github.com/dsblank/activitypub
It would be great if we could combine common functionality into a core library. I'm just now starting to work on packaging up the AP+database logic. If I can help make this activitypub library useful for GetTogether, I'd love to. Help and suggestions welcome!
Hey, are there any updates on this? I really like the concept of GetTogether, and think adding ActivityPub support could make it a welcome addition to the fediverse!
It would be great if we could combine common functionality into a core library. I'm just now starting to work on packaging up the AP+database logic. If I can help make this activitypub library useful for GetTogether, I'd love to. Help and suggestions welcome!
This would be great! :D I'm helping Human Connection team to implement ActivityPub in their future events/meetup feature! ;)
@dsblank
It would be great if we could combine common functionality into a core library. I'm just now starting to work on packaging up the AP+database logic.
It's great to hear that you are moving forward on this topic. I don't know if you've heard it yet, F-Droid also considers using ActivityPub for integrating repositories into the fediverse. I even featured your library and this discussion in our forum topic we have where we discuss on how to do that the best way. To recap the discussions, there were opinions about federating directly with libraries like yours, but towards the end it tended more to using existing platforms like Mastodon or Pleroma for not having to think about implementing the ActivityPub standard. Now I'm curious what you as the developer say about the state of the software, is it already usable for usage in GetTogether or F-Droid?
So beside GetTogether, we from F-Droid would also highly appreciate sharing that core library of ActivityPub related stuff.
What about the CalDAV component of WebDAV? This is used by NextCloud for their calendar synchronization, which I assume will be integrated in some way with the AP-compatible social app they have started to develop.
There are at least three other free code projects that set out to offer federated replacements for the event organizing functions of MeetUp and FB. As well as Human Connection, there is Calendar.social, who plan to implement AP, and Mobilizon already implements it. There's also Communecter, who have event calendar functions, and have discussed implementing AP (they already support ActivityStreams).
From a user POV, it would be great if I could announce an event on instances of any one of these platforms, and get RSVPs and comments from users on any other instance. Allowing users to follow each other and get announcements of new events would be pretty important too. If we could create group accounts that multiple users can admin (eg a 'Python Lunch in Barcelona' group), and users can follow like any other user, that would be awesome too. I'm no expert, but I suspect that both AP and CalDAV support on all 4 platforms would be necessary to make this all work smoothly.
updates about events and AP: https://socialhub.network/t/federated-events/226
ActivityPub already has the necessary protocols to support this, I'm not sure what CalDav adds or who else is using it.
I'm not sure what CalDAV adds or who else is using it.
Calendar apps are using CalDAV. Like, I can subscribe my phone and my calendar app on PC on a CalDAV on the actor's CalDAV file, and get all the events from that community I need to know about right where I see all other events, and get notifications
You can do all of that with an iCal feed too, which is a much simpler spec to implement that the full CalDav
Maybe it would be useful to check out the ActivityPub models used by mobilizon https://joinmobilizon.org/en/ which has been launched recently and seems similar in some ways to GetTogether. It's coded in Erlang/Elixir. You might find some documentation sur as the model for an event https://framagit.org/framasoft/mobilizon/wikis/spec/event
I have played with activity pub in python, here is some MIT licenced code you can reuse if you are interested: https://github.com/sgenoud/federa/tree/master/framework
It is undocumented, uses Flask, but it already does the boring, annoying parts (around identity and signing). Not sure I have the time to help, but ask anyway!
Hey there, I can only recommend to listen to https://librelounge.org especially the recent and upcoming episode and also upcoming videos/tutorials as one of the authors will do a generally purpose AP server in Python.
I was just looking at how webfinger might be implemented and the thing that struck me is how to differentiate between the types of actor.
First decision: which field do we use to look up each actor? My suggestion:
User - username Event - id Team - slug Organization - slug Place - id
This is assuming username and slugs don't change. Of course we could also add slugs to the event and place models to make webfingers more readable.
Second decision: what kind of identifier can we use to make sure the webfingers for two different actor types with the same ID don't clash? Probably some kind of prefix for the non-user actors.
Apart from alphanumerics, webfinger allows accounts to have the characters -._~!$&'()*+,;=
(whether or not implementations respect these characters is another issue).
So picking one arbitrarily, webfingers might look like this:
paulkiddle@gettogether.community event+12345@gettogether.community team+london-open-mics@gettogether.community org+open-mics-uk@gettogether.community place+12345@gettogether.community
How does that sound? (Apologies if this comment is a bit of a mess, I'm quite tired!)
Slugs will change if the team name changes. Technically usernames could change too, though there's no mechanism to allow that yet. But I'm not sure that matters to webfinger a long as it's "accurate as of right now" and the ActivityPub id's and paths use the immutable database IDs
The first question to answer is what to use, since GetTogether isn't like Mastodon. What exactly does it make sense to publish? Does it make sense to expose User feeds? Place feeds? Or should we just expose Team feeds, with User and Place as just references within that?
I think the minimum viable implementation would allow somebody to "subscribe" to a Team only. The feed for that team would be it's Events, with an ActivityPub "create"(?) post for each one. I think that would be enough for somebody to follow a GetTogether team from Mastodon, for example, and see their events as posts.
I think mastodon does expect actors' usernames to stay the same - will need to check whether that is just for the actor json or the wefinger too.
As for which actors to use, I was going by https://github.com/GetTogetherComm/GetTogether/issues/60#issuecomment-401898094
Yeah that's a very ambitious list to try and tackle all at once. Let's start with Team and learn as we go.
As I was about to comment that this is becoming more important with the change in payment model on meetup.com (2$ per person per meetup), I've just found out that they have retracted this change from their blog (too many people said they would leave?)
Archive of announcement : https://web.archive.org/web/20191015032536/https://www.meetup.com/lp/paymentchanges New page on the same URL https://www.meetup.com/lp/paymentchanges
What is the status of ActivityPub support for Get Together? In the meantime there is a new, similar project created, called Mobilizon (already federating) and we also have Gancio (not yet federating). This federating is now easier with the new AP Event type.
Would be great if all those alternative open source events services could federate. Cause that is how you can beat the corporate ones.
I'll be honest, I've seen way more interest in an ActivityPub implementation specifically than a federation option generally. I get that people like AP, and it works well for things like Mastodon, but there just doesn't seem to be a lot of demand from people who want to host their own instance of GetTogether or any other Meetup alternative.
Here's my current feelings on this bug:
Here's my current feelings on this bug: Converting GetTogether data to ActivityStreams format is relatively easy and already doneSyncing event data between GetTogether instances using JSON and an API is relatively easy and already doneActivityPub itself is geared towards passing messages between people, not federating event data between platformsImplementing ActivityPub in GetTogether requires significant changes that would make GetTogether more of a social media/messaging platform than an events platform (users will need inboxes/outboxes, encryption keys, ability to follow/unfollow other users, etc)At this point I just don't see a significant value to GetTogether or it's users to justify that workIf somebody else feels differently and wants to do that work, I'd be happy to accept it
—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.
I'm only asking this from an end user point of view, and a Mastodon server admin point of view.
There are two kinds of federation;
Federation between events services. So a user on one of these services can subscribe to remote events from the same service and from another service.
Federation between events services and social media like AP services, like Mastodon. The primary use of that is to fetch events in people's timelines, so they can reply on those events. Mobilizon has this working. A future feature can be that people from e.g. Mastodon can subscribe to an event (saying if they are attending or not) from their timeline, but this would require more AP types I think. Another way is to give Fediverse users the possibility to subscribe to an event via the events websites using Oauth.
I think 1 has the highest priority, but as said, I'm an end user and Mastodon admin, and not a coder.
Good luck with whatever you decide to do.
Federation between events services. So a user on one of these services can subscribe to remote events from the same service and from another service.
What kind of "events service" do you mean by this? Like a calendar provider? That should be pretty easy to do with an existing library or project.
Federation between events services. So a user on one of these services can subscribe to remote events from the same service and from another service.
As far as I was able to tell, from reading the ActivityPub specification, there's no way to federate events between services without going through a user's subscriptions. As I said above, AP seems geared towards inter-personal exchange and not inter-system exchange. Syncing events can be done today with either the ActivityStreams endpoint or the simple JSON endpoint, both of which are already in GetTogether. Or, as with @Nutomic 's example of a calendar provider, with the iCal feeds provided per-team and per-user already.
Allowing a user in one system to RSVP to an event in another system is quite a bit more difficult, we would have to extend our User and UserProfile models to identify local user accounts from remote user accounts, provide a way to authenticate a remote user account, and provide a way for a remote instance to send notification messages to a local user's email without giving their email out to those remote instances. Spam control would also need to be a consideration at that point.
What kind of "events service" do you mean by this?
Usually when talking about federation it means different instances of the same or similar software platform being run by different entities. For example, you could run your own instance of GetTogether on your own domain name, and share events and users with gettogether.community and vice-versa. Or something like loco.ubuntu.com could share their events with gettogether.community and allow users from one site see and RSVP for events created in the other.
As far as I was able to tell, from reading the ActivityPub specification, there's no way to federate events between services without going through a user's subscriptions. As I said above, AP seems geared towards inter-personal exchange and not inter-system exchange.
Not necessarily. While most implementations today focus on the User actor type, ActivityPub also supports Group, Organisation, Application, and Service, which can all have an inbox/outbox: https://www.w3.org/TR/activitystreams-vocabulary/#actor-types
Also note that many ActivityPub projects have a sharedInbox
on the server level, for scalability reasons. So you don't actually have to deliver to individual actors.
I would highly encourage to consider implementing ActivityPub in some way. It would be sad if we get a new batch of open source meetup replacements which don't talk to each other. Sure you will find some pains and things to work around, but in the end ActivityPub is more of a framework than a strict spec. You only need to implement the parts you need.
I guess the questions the GetTogether developers need to have clear answers to are: 1) do you want GetTogether instances to be able to federate with each other? 2) do you want GetTogether instances to eventually be able to interoperate and share events data with instances of other platforms that have events calendar features (Friendica, Hubzilla, Mobilizon, Gancio, Gath etc) 3) do you want to achieve 1) and 2) without having to define your own federation protocols from scratch, and with at least some assumptions about interop already shared with other projects (ie those defined in AP)
If the answer to 1) is "no", the whole discussion is moot. If the answer to 2) is "no", then it only matters to GT devs what protocols they use to achieve federation of GT instances. If the answers to all three questions are "yes", I guess it's up to some coders familiar with implementing AP to demonstrate why it's a good solution for all three. Maybe someone could put together a proof-of-concept demonstrating federation between GT and Friendica events, and showing how that's helpful for users of both?
I agree to @strypey – there is a place to GetTogether: ⬡ https://conf.activitypub.rocks
So is GetTogether federating with mobilizon and other fediverse instances?
We now have a standard for federated interaction between services, called ActivityPub: https://www.w3.org/blog/news/archives/6785 https://activitypub.rocks/
We already have Mastodon, Pleroma and PeerTube in our Fediverse. Soon there will also be Aardwolf and several other social interaction engines. It would be cool if you join in.