Merge FairSync and InCommon or make it interoperable

In the D-A-CH-Region there is a Fairmove-IT-Movement working to connect the most relevant platforms of change like

We decided to start as a centralized system (over openfairDB) to get it running, but want to be federated as soon as possible.

We will browse this forum and your documentation to see how this can be connected. FairSync just started. and Prezdecheznous is definitly intresting to connect, so we might us InCommon at least to sycronize to all GogoCarto-Platoforms](

More basic infos you find here:
Milestones and Protocols are done in


It would be very useful if you came to OFFDEM next week-end (next to FOSDEM) since a number of interested people from the ActivityPub community will be there for the SocialHub gathering. Otherwise the upcoming InterMapping event @natacha mentioned would be the next best moment.

I will check if somebody form opfenfairDB or FairSync can join there (

In the end it is also a financial question. For is it is traveling cost and timewise quite an investment. Do you have an idea?

Yes we certainly could think about funding some travel for Intermapping, I think OFFdem is to short in time to make it worth a move if no one of your team is around Brussels (for fosdem for example).
I ll do some update about intermapping next week +check the notes about the OFFdem Incommon meeting that will be reported here.

Sorry @natacha and @how
This time nobody from openfairDB or Fairsync is able to join Offdem. Next time with more preparation.
I will have a call with @yala today. Lets keep in contact.


Thanks for sharing the link!

How is it possible that I had never recognised it before, yet?

It seems to me, that if they added internationalisation to their UI only, and a less french-oriented domain name, that they could attract a lot more users.

@yala I do not really understand what you mean, IN COMMON is suppose to be the base to foster this internationalisation by means of sharing the data.

I used the term internationalisation here in the technical meaning of translating the user interface strings. All the elements are written in french, and I didn’t find an option to switch the locale. Adding a layer of internationalisation to the interface would allow to translate it in many different languages.

Update about fairsync:

  • For Synchronization we want to use calDAV as a widely spread standard:
    • calDAV for Events (which is interoperable with Nextcloud)
    • cardDAV for Locations (which builds on vCard)

ActivityPub will become interesting for us a bit later, when it comes to spread news and ratings.

Main part of fairsync will be a microservice to detect and handly duplicates.
This microservice can also provide an activity pub endpoint.

I have created an overview sheet, comparing datafields of openfairDB and vCard, which maches very well:
As soon as your fields at inCommon are documented, I will add them too.

@how @natacha: Do you mind just orientating the fields of in Common along the speicifaction of vCards for locations and calDAV for Events?

We would very much love to be you delegate for the first version of data syncronization. Could you please send me a file where I can see, how gogocarto-data is structured?

1 Like

*DAV compatibility would be interesting. I need to do a bit of research on this, but if people are interested, it could become part of a milestone. Yet ActivityPub has probably more priority for IN COMMON. I guess @ekes from Radar would have an opinion regarding iCal data format, as suggested in a previous discussion we had about Mobilizon and alternatives.

I’ll try to do the same and see where IN COMMON stands.

1 Like

Amazing this makes sense, we certainly could integrate the results. IN COMMON will encourage rich of information, to feed a relational model.

I think you should ask this directly to @Sebastian but I generally think it is documented here:

I agree with @how this is important conversation that we want to continue having especially as Mobilizon is developping, and yes the conversation about Ical

1 Like

Thank you for the nice overview of possibilites.

I think it’s good here to separate between the wire protocol (DAV, based on XML), and the vocabulary used to depict the objects in the serialization. Where vCard is an accepted standard, synchronisation with an XML-based protocol will always come at the downside, that it is not accessible by browser clients.

This would be a strange decision, given that we are moving more and more logic into the browser clients, and render our servers dumb storage engines, connected with a JSON-via-HTTP protocol.

I am not sure if I would be willing going down the road of reviving XML-based standards for the core of a synchronisation logic, if we have JSON(-LD) available and at hands, especially for new developments.

If people wanted to have access to their events via a DAV endpoint, we can always publish an iCal feed, which people may add to their Nextcloud as well, and have it accessible from there.

In general this conversation seems more about which vocabularies for events (iCal? and locations (vCard? exist, and how we can map between them.

Secondly the means of synchronisation and federation, the protocol, becomes a second degree question for interoperability (neccessary condition), if the first is answered (sufficient condition).


I believe this is a key insight. Separation of data semantics from data serialization.

This has allowed a project I am working on (openEngiadina) to directly use events from Radar with zero-coordination. The trick is that Radar uses a well known collection of properties and classes (schema_org) and has the content embedded on the Website (using RDFa).

Semantics are collections of properties and classes. These properties and classes are defined independent of the context they are used in, independent of data representation format and independent of transport protocols.

There are many existing collections of properties and classes to describe things - these collections are called vocabularies or ontologies. Examples include or even ActivityStreams, which defines the properties and classes used in ActivityPub.

Data serialization formats include JSON-LD (as used in ActivityPub), Turtle, XML, embeddings in HTML. Choose whatever fits the client best, the content itself is the same.

It turns out that ActivityPub is basically a protocol for synchronizing such data (Linked Data) from client to server and server to server. Maybe that’s a way to make FairSync and InCommon (and openEngiadina and the Fediverse and many existing data repositories) interoperable?


ActivityPub ist still our vision.
Today we had a first call after along break to pic up this topic.
Our first mvp is to connect and, therefore we will continue with our first steps in a project so called GoodDB and might extend it to activity pub later.

yes, we have been seeing the acceptance of fair sync by NGI0 this is great news.