Events / calendar

[AyaMorisawa]

Invite (local?) users to events and filter / show events the current user is invited or public available events.

Originally posted by @pwFoo in https://github.com/syuilo/misskey/issues/3110#issue-377169054

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[ssmucny]

I would be willing to start implementing this feature. I see this as broken down into the following components (roughly in order of development):

• Add database support to attach an event to a note
• Add/modify API endpoints to manage event / include event in notes
• Add UI elements to create and display an event in a note
• Federation of events with other services (Mobilize, Friendica, etc.) / export events in iCal format
• support for users to respond to events (RSVP)
• Dedicated views/API for events
  • calendar
  • event query/search/list

I can break this out into separate issues and provide HLD/LLD for the components or include them here. I am in conversation with some companies that are interested in this that may be able to provide funding as well (waiting on RFP).

[ssmucny]

Database Events

• Add new table for events
• foreign key 1-to-1 with notes (each event has 1 parent note, a note may have an event). An event will be considered a type of note that has extra properties.
• contains (in addition to normal note properties) start/end datetimes (end is optional), title, metadata
• index on start/end
• metadata is jsonb field with key/value list of all optional fields (just text values) to enable ad hoc filters/searches
  • location
  • neighborhood
  • transit
  • virtual
  • cost
  • etc.
• If the parent note is deleted, then the event should be deleted

[ssmucny]

Events API

• Modify notes API to return an event member in the note object if present (similar to renotes)
• events, because they are a type of note, will have the same ACL as notes (direct, followers, home, public, local)
• Add new API endpoint to search for events with following options (options should be included as query/URL parameters to enable permalinks to searches)
  • list of users to use as source (like antennas) (probably just user IDs, but maybe support usernames if starts with @[%40 encoded])
  • start date and/or end date or start and/or end noteId (default to today as start date). Allow several keywords like today and tomorrow in addition to ISO dates
  • limit (default 10)
  • sort by (created at or start time). default to start time. If created at then sort newest first, if start time sort oldest/soonest first.
  • metadata filters (mapping of string -> [string]) where each list of strings is an OR for the key in the metadata object. a value of (BLANK) allows NULL to match. The keys are ANDed together. keys that don't match other parameters are treated as metadata filters.
  • ex: https://thecle.land/api/events/search?user=abc123+ef347&start=2023-03-31&neighborhood=Downtown+Flats+Ohio%20City&cost=Free+(Blank) will find events posted by user IDs abc123 and ef347, that start on or after 2023-03-31, and have metadata fields: neighborhood that is one of Downtown, Flats, or Ohio City, and cost either not listed or Free.

[acid-chicken]

Thank you for your work!

• foreign key 1-to-1 with notes (each event has 1 parent note, a note may have an event). An event will be considered a type of note that has extra properties.

Is the reason for this design because the notebook is responsible for outlining and describing the event?

[ssmucny]

Thank you for your work!

• foreign key 1-to-1 with notes (each event has 1 parent note, a note may have an event). An event will be considered a type of note that has extra properties.

Is the reason for this design because the notebook is responsible for outlining and describing the event?

Yes. The note text could be considered the description of the event. Also any attachments to the note would be inherited as well by the event. The event just adds new properties that are event specific. An alternative would be to add new columns to the note table for events, but they would be empty most of the time. Separating the event specific properties into a separate table should improve clarity.

[acid-chicken]

Then, maybe #8362 should be accomplished at the same time.

[ssmucny]

I have opened a draft PR to track progress and discuss implementation at https://github.com/misskey-dev/misskey/pull/10628