Concept for events in Diaspora

I am doing my master thesis at TU Dresden right now. The subject is federated events in distributed social networks, speaking: implementing events into Diaspora. There have been many requests for that feature and I am desperately willing to contribute to the project myself.

This thread should be about discussing my concept, so that it can later on actually be included into Diaspora.

I have read this and will try to keep in mind the advices in there.

My concept is different in a major issue, though: I am not planning to implement events like a poll, as @jaywink stated, but as a separate object not related to a post. This will have several advantages, first of all an event may be owned by multiple users. This is crucial because there might be multiple real-life hosts as well.

There should be another box in the sidebar called “My events”, which has a small monthly calendar view for a users upcoming events and a “create new” button.

Creating an event will be in a separate view, that will be reachable by default REST-style route /events/new. The interface should be not much different than the one for a post, except that we need more input fields. An event will have a name, a location, a datetime object (later to be extendable by “all day”, “end”, “multiple days”, etc) and a description. Images may be added to an event just like to a post.

The description may hold tags, so that the event can be categorized and filtered into topics.

In the stream an event will be shown just like a regular post, just having some more key data templated next to it in a certain way.

Participation to an event should be done analogous to liking a post. In fact, this may even be the same code, just that it would not say “like” but “attending” in the frontend. From my experiences on other sites, most people who do not plan to attend an event, just ignore it, so there is no need for a “not attending” feature for now. This is to be discussed, though.

Analogous, inviting people may work the same way as resharing a post plus mentioning users that are to be invited. This is viewable within the chosen aspect.

As stated, multiple users may host an event, so there must be some way to add more users to it. I am not sure yet, how this should be done and would ask you for your thoughts.

Finally, an event should be available as iCalendar format, so that a user can subscribe to the Diaspora events he will be attending using his favorite calendar tool.

Those are my first conceptual thinkings about Diaspora events. Please feel free to comment, advise, criticize and tear it apart. As @jaywink stated, its best to come up with plans at an early stage to have it done right in the long run.


Note: This discussion was imported from Loomio. Click here to view the original discussion.

It looks good, to me. You might want to take a look at the geolocalisation on OpenStreetMap currently going on for localisation.

There’s currently a WIP pull request for events which you might want to liaise with.

Thanks for opening this discussion!

I must say I still would personally prefer to have events mimic the way polls work. This would fit in really nice imho with what we have currently. Having the Event a part of a StatusMessage doesn’t mean we can’t have them show separately in the sidebar for example, or that we can’t offer a create view that looks different from the post. Everything in Diaspora works through posts (well, except conversations), I just think it is a really neat way of organizing things.

Of course, this method would totally kill the concept of multiple owners. But I think that will be tricky to do anyway in a distributed network. I see you don’t mention federation anywhere in your details, which is going to be the largest issue to solve with events that have multiple owners.

Totally agree on everything else.

Thats right, but as federated events is the subject for my thesis, thats exactly what I am going to have to figure out.

Are you making progress on your thesis?
I know API Diaspora could still help you with something.
With federation events.

Are you making progress on your thesis?
I know API Diaspora could still help you with something.
With federation events.

Not really. I mean, He has to create the whole hidden machinery. The only thing API enable is the possibility to interact with this machinery from outside diaspora* following an authentification/autorisation standard.

What do you mean by “the whole hidden machinery”? I am still trying to figure out the federation functionality in general.

What do you mean by “the whole hidden machinery”?

I.e: the models in db, the controllers to manipulate the models and the views to render the events. The API won’t be any help for you to do that. All that the API does is to enable the possibility to acces these ressources through a classic OAuth flow from outside the website, that’s all.

You can try the following way: figure out how to implement such a feature for a centralized social network. Then, it’s pretty easy: an event is an object with multiple properties (a creator, multiple administrators, a date, a place, maybe some other things) and actions (modify the place, the date, etc.) From that point, you can setup your models, your controllers, your views.

Then, you can start to think in a federated social network way: how to spread this object around multiple pods? diaspora works in a push mode: when a new post is created, it is just sent to the concerned pods. It has flaws but it works, most of the time. You can basically start to look at the way post federation work.

The main problem you’ll have to figure out is how to replicated modifications around the pods? Currently, posts and comments are immutable. Once created, you can’t modify it. That’s easier. Events have to be modifyable. So you’ll have to figure out how to ensure that the event is in the same state all around the pods.

Hope this helps.

@augier thx for your detailed answer. It will definitely help me to stay on track. Concerning the modification sync with remote pods, @jhass proposed on IRC to adapt the comment/like functionality. I will have to look into this.

Closing in favour of the active discussion.