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.

Dear @natacha and @how

With Fredy @naturzukunft and Markus (Open fair DB) we have got two developers ready to develop the Interface for InCommon and Gogocarto.

Where can we find your specifications?
Can we do a call? All 5 of us?
Fredy @naturzukunft just started our first draft of specifications: Now we are open for your comments.


Hi there,
we fond some distributed documentation about the incommon api. is there somebody who has an overview ? I found but didn’t understand it.
I’ve to try to understand https :// and IN COMMON Models

hi @wellemut great to see this.
We should talk asap because there are many things that you are approaching that have already been worked out by IN COMMON Please check

Also we should update you with the latest work done in collaboration with @pukkamustard and openengiadina concerning linkdata specifications that are really important for all of this.

Is there a moment when we can do a group call

Hi @wellemut, thank you for reaching out.

I had a look on @naturzukunft’s API draft and I have three comments from the top of my head:

  1. the licensing information is incompatible: you’re going for Public Domain, but we’re going for AGPL – which means we deliberately want to give an advantage to free software developers over any appropriation available using PD.
  2. Our Place model (see also Resource) is quite different and generally we take a modular approach, e.g., an email is not a property but a relation.
  3. We’ve been discussing with @pukkamustard about moving towards a graph model which would allow us to support a dual approach to data synchronization: interoperability with Linked Data on the one hand, and with peer-to-peer replication on the other hand (e.g., with P2PCollab).

For the latter point, we’ve submitted a joint research proposal to experiment with P2P protocols and graph data models, so this is where we’d like to evolve our current specification, which is currently too much in flux to be presented as a flat document. That said, the source code already provides quite a lot of documentation on the relations between models and the attribute specifications – run rails erd from the source tree to generate the diagrams. I suggest looking at the specs folder in the request-specs branch to get an idea since this is where the most recent reflection appears. I’d be happy to dig into it more, but please have a look at openEngiadina’s Geopub demo[1] to get an idea where we’re headed… @pukkamustard wrote a couple of proposals that you might want to read and comment on as well: have a look at the linked papers on the Encoding for Robust Immutable Storage (ERIS) demo page.

  1. OpenEngiadina and P2PCollab are also supported by NGI0 grants, so we’re happy to collaborate. ↩︎


Maybe can help you read the diagrams.

Maybe we can do an AMA so that you can lift any doubt on our current approach and why we chose what we did…