Sustaining events

Context

I observed suboptimal and unsustainable patterns in several groups that I organize events with.

For example Berlin Hack&Tell started out with meetup.com/berlin-hack-and-tell. In the beginning this worked well and helped bootstrapping the community. But capitalism and the process of enshittification over the years (especially after meetup.com was being acquired multiple times) made it insufferable. Recently they switched off the API we relied on without upfront notice. Also the whole site gets buggier every time I have to use it and I already lost data on this platform after Internal Server Error.

This is all very frustrating but not even the the worst of it. Their model is now so that if we do not pay the expensive fee - the group will go to the next entity that does. That means that the meetup-group we fostered with over 10 years and 100 iterations will be given to some random stranger that is willing to pay. Most likely to get a ROI by bothering our community with bullshit they get paid for.

A lot of the alternatives to this particular platform are just in an earlier stage of the capitalistic lifecycle.

I also saw struggle in several groups that provide calendars with a view on a set of events like days.protocol.berlin and devconnect.org. Both currently use different closed products (fillout.com and notion.so) to manage the data.

Then I saw a talk about smoke signals - this resonated and think this is the best approach to the problems I observed. This project is still early - but I think they have a better approach to the problem than all others I have seen so far.

A big part of it is the focus on well-defined data and the efforts of lexicon.community.

This fosters a sustainable path of getting from a product to a protocol and giving the community the chance to outlive. A lot of the alternative are just products again - often with extra steps to obfuscate that fact.

Lexicon

The events.smokesignal.calendar.event lexicon was a great start and the migration to community.lexicon.calendar.event showed that the upgrade path is there. But for the usecases I mentioned: some things are still missing. So I am writing this post to discuss a potential next step of this evolution.

Multi-Day events

Both current versions of an event have startsAt and the endsAt (optional in the community version) to define the time. This would work well for meetups like BHNT - but not so well for ProtocolBerg or DEVConnect.

We now could come up with a complex data structure and UI to define time-layouts of an event - like this is how we collect things for the calendar at days.protocol.berlin:

Or we break down events in sub-events and allow links between events. This makes things simpler and opens up more options. E.g. for ProtocolBerg then there would be 2 sub-events where each day is one event and both reference a parent event1. This not only makes the structures much cleaner but also e.g. allows a community.lexicon.interaction.like to only reference one of the days. Or the whole event by referencing the parent.

This then could also allow event-relations other than Multi-Day-Event. E.g. afterparty_of_event, talk_at_event, successor_of_event, in_series_of, ..

App linking

Events are often augmented by apps. These should be available through the published event data. Apps can be things like:

cfp / schedule (e.g. pretalx)
chat (e.g. matrix)
ticketing (e.g. pretix)
streams/recordings (e.g. streameth)
Q/A (e.g. meerkat)
pictures (e.g. grain.social)
code (e.g. tangled.sh)
blog (e.g. [whtwnd(https://whtwnd.com))
notes (e.g. fileverse)
..

It should be an array of “URL (link to app)” and a well known type describing things like the list above. For example for protocol.berlin it would be something like:

For authenticating between apps a system like zupass.org can be used. E.g. if a user has a ticket via pretix - they could authenticate for a special chat room in [matrix]. This can basically give the user shared accounts across apps.

Venues

The location handing for events already improved a lot changing to the community lexicon and leveraging community.lexicon.location.address And there is more work ongoing in this area. I am especially excited for the potential "claiming" of venues - I think this can already enable a lot of possibilities. E.g. it could be nice if venues could attest a certain event is happening there (e.g. a badge)? In the meantime we can already kinda enable it by a convention that I would like to propose and already am using for a couple of events. The convention is that if the event-name starts with an "@" - then it is assumed that a venue with a presence in the at-protocol under that handle is referenced.

Image(s)

We need to add some images connected to events. E.g. a cover-image. A lot of people are very visual and this is needed to help them and improve also the UI.

RSVPType

Currently SmokeSignal assumes a simple RSVP system. This is the reason I could not create a protocol.berlin event there as people then could just RSVP to the event and show up at the door with good reason. But we use another system (tickets.protocol.berlin) as we have limited capacity and cannot just let everyone RSVP. So we would need to refuse access to people even though they might have sucessfully RSVPed. So I decided to not create the event on SmokeSignal in the first place. Even though it might be nice as we also have a AT-Protocol talk there:

The RSVP/ticketing system should be exchangeable and extensible. It should have a type (e.g. community.lexicon.calendar.rsvp, Pretix, ..) and an URL. Maybe it can also be combined withe apps record to keep things clean and simple.

For the plain RSVPs like community.lexicon.calendar.rsvp we should also add a way people can answer questions with their RSVP. E.g. via meetup for our BHNT event we always ask "Do you have a hack to present?" - to completely migrate away from meetup.com this would be a good feature to have.

Profile linking

It would be good if events can link to at-profiles connected to the event. E.g. the organizers or speakers of the event. It could be a list of at-profiles with their role (Organizer/Speaker/Sponsor/Host/..) in a well defined way. e.g.:

at://dod.ngo to community.lexicon.calendar.event.role#organizer
at://ligi.de to community.lexicon.calendar.event.role#speaker
at://c-base.org to community.lexicon.calendar.event.role#venue

Recurring events

This is a huge can of worms. Maybe it should not even be attacked in the next iteration. But at some point it would be good to support it as a lot of events happen on a regular basis. One option is to bake it into the lexicon with a field like RRULE in ICS.

Thoughts outside the lexicon

In the last section we discussed changes to the lexicon - in this section we will discuss changes that would need no change of the lexicon. These could either be changes to SmokeSignal or other apps operating on the lexicon we discussed before.

Barrier to entry

Currently it is easy to participate if you have a PDS alreay in place (e.g. via your bsky account) - but if you do not then this provides a barrier of entry. I especially saw this "Oh I need to create an account on another site now" as a point where people drop off. Ideally an app like SmokeSignal would provide a PDS for these users. With the credible exit of at-protocol they are then free to move later anyway.

Interactions

The apps could leverage the existing community.lexicon.interaction.like pointing to the record of an event. This can help surface interesting events to users and also serve as a bookmark. Also a follow interaction could be useful - there he question if app.bsky.graph.follow should be used or if we need to have a separate graph for this use-case. Maybe in the beginning we use app.bsky.graph.follow and see if the need for a second one arises. The advantage could even be that things work magically already by the at-proto graph. Because chances are good that at://ligi.de is interested in events fromat://c-base.org when the follow interaction was already on bluesky. Bluesky could also be used as notification system. I saw this pattern with tangled notifications and think it could be a nice way to go. It could even be done to make people aware. So if a user follows a venue or event-organizer and this one publishes an event - the user could be notified via a message on bluesky - making the user aware of e.g. SmokeSignal in the first place.

Area search

Now that with the new the new version of SmokeSignal events can happen in all locations over the world - it would be good to be able to search for events in some area - e.g. in the city the user is currently residing. Currently it shows me all events all over the world - most of them are not relevant for me as they are too far away.

Conservation

Often the later parts in the event-lifecyce are forgotten. I just recently searched for a video of a talk I have seen at an event - and it is nowhere to be found. I think it would be really nice - if e.g. all people that liked an event would collectively pin the videos and other content of the event. This could also be some external service that operates on the data. The same way there can also be services that e.g. transcribe videos or create podcasts from the published media.

@ligi.de

2025-05-27T13:16:08.910Z