Hello, happy to be here and we are boom for maintainers, Mayell and Ivan.
This will not be a heavily technical talk, hope you, it's fun for you.
The talk is called contaminated infrastructures and it will be a talk about contamination
in different forms.
It suggests how we can allow ideas, code and communities to issue each other for
mutual benefits.
How we approach and navigate the complexity that is within the project, how we communicate
with the project, but also how we build the features and how we decide the roadmap.
It is also, we hope an alternative path to big tech dominance visions and about how
the Fedivers and the open social web as a whole can enable building things that are
greater than the sum of their parts and also about why it is important for now.
To talk about contamination, it is easier to start from the opposite, which is purity and
we know that Silicon Valley builds for purity.
They have this idea that they want to scale by eliminating variants, they change acquisition
over partnership, they create all that garden over ecosystem and everything they manage
the users and the data, they try to monetize over it.
So in a sense, big tech tends to produce monocultures and we know that monocultures are fragile
and when a platform identifies, users are nowhere to go with their relationships intact.
When a company strategy shift and their communities discovered that their infrastructure
was only rented and the landlord can change the rules or keep them out any time.
We've seen this in agriculture and the same things is happening also in tech.
We know by a corridor that big tech needs to ensure that the platform platform is the
same path.
But communities need viable alternatives, democracies need social infrastructure that are
public common goods, which does not involve only the code and the software developers, but
involves the maintainer, the translators, the user, the social researcher, the hosting.
So a whole ecosystem that needs to be sustainable and needs to work according to common
goods.
Yeah, so we're trying to take a different path to that and build an infrastructure
that evolves through encounters and through all the people and projects who get involved
to build components that interact in combined ways that even we can't predict, organizations
that reshape each other's roadmaps and resilience through entanglement rather than control.
And we embrace complexity and plurality.
We think that's an asset and not a problem to be hit in a way.
And yes, that means a lot of people don't really understand what our project is.
I hope it becomes a bit clearer today.
At first glance, bonfire looks like yet another micrologging platform, but it tries to go
far beyond that.
You can, for example, share long form articles, like blogs, events, book reviews, videos,
and much more.
And unlike traditional social networks, where connections are just like friends or followers,
bonfire goes beyond that binary and you can organize your contacts in circles, like family,
a book club, foster them peers or any group.
And when you post, you can choose which circles can see, interact or comment.
Each circle also has its own feed and you can even share circle with itself, share circle
itself publicly or with other circles.
Bonfire puts communities in control of their experience.
And that means also embracing consent in social networking, not just by supporting DMs or
private groups, but by putting circles and boundaries.
And so when you share posts, you can choose which circles can see it, but also comment
or interact.
And this enables more collaboration and trust, instead of looking at social networking as
like a global town square, you can have groups and choose who you want to interact with.
And bonfire is also modular.
Every piece of bonfire is built as an extension that can interconnect with other extensions.
There's no core app, and this means that features can be toggled on or off either at
the instance level or by individual users.
And you can easily add your own extensions that you build or fork a specific feature if
you want to modify how it works without having to maintain an entire fork of a big
monocultural code base.
This means that communities can assemble their own apps.
There's not one bonfire app, each community has their own flavor.
They can enable what they need, and people can also build their own extensions as they're
as saying.
And this means bonfire becomes different things in different hands and adapts for each
context.
An activity pub is the main protocol that enables that for us.
It enables having not just notes, short text, but also events, articles, audio, any type
of activity and content.
A whole vocabulary of social activities.
And we're building for communities who don't just want to do one thing, but want all
of those things or their own selection, their own version of what those things represent
for them.
So, yeah, we are building for communities that different needs, and where their essence
came, became a meeting point.
So, all the kind of activities events, notes, articles, book reviews, and whatever, can
all throw to the same space without losing their shape.
So, they all would be previewed as the activity that they are.
The members doesn't need to join different kind of software for different kind of content,
the Fediverse came to you.
And as the community evolved, new extension, and new integration can come in the instance,
today they need discussion tomorrow they will need events, that they after they may need
collaborative documents and such.
This means no more forcing the community to juggle between different apps, the bonfire
space can bring content from peer tools like peer to borgos directly to their feeds.
This means that doesn't mean that centralized everything into one platform, centralizing
everything into a platform.
Community members can still use the best tool for each job, like sharing a video or an event
on Gansho, a 3D design on manyfold, but it's all seamlessly integrated so that people
can follow watch interact directly from their social space.
And we are working integrating client to server API, apps like Laughty, which is a community
calendar, they can simply connect with bonfire.
They don't need to build federation from scratch or common social features.
Any app can post, comment, like and follow, bonfire takes care of the activity by planning
and basically it's a breach for both protocol and for the app ecosystems.
And so why are we here in this room today?
After having given a talk at the social web room yesterday, we thought it was important
to go beyond that community and see how we can bridge protocols, how we can have a network
of networks rather than separate platforms.
So to begin with, we already bridge with ATPOTO, thanks to the Bridgie Fred project,
and that works pretty well, and would love to bridge with matrix, XMPP, or whatever else.
On the ATP, for example, you can post on bonfire, people can follow you from ATPOTO,
and your posts will appear in their feed, they can comment and they've come in superior
in both places.
That's open network effects and action across networks.
We don't have to live in platform monocultures, open protocols, communes, secure messaging,
private groups, contacts, the web spaces, and real community control to counter toxic spaces
and surveillance with consentful trust and safety community with tools.
This is how we can break, lock in, and build in networks we want.
And the good news is that there is matrix and activity pub bridge, I don't know if the
person is here today.
We spoke yesterday, and they have a bridge ready.
So it's called Kazarma, and it puts Federation Action by letting you seamlessly connect
matrix and activity pub networks.
Private messages and other content can flow between matrix users and dozens of other
Federer's apps.
At the moment, of course, it only works with non-incrypted messages, but we're currently
working on implementing and to an encryption bonfire.
There's another project called Emissary doing the same, so we're doing this with a shared
spec with a focus on interoperability and standards working with a social web foundation.
And so we'd love to find ways to interoperate with other networks as well.
So we found this website called RVMLS yet from the matrix ecosystem.
So there has been apparently a lot of work already in exploring and testing MLS for matrix.
We don't know where that initiative will go, but it would be great if that can enable
bridging.
As we said at the beginning, Federation was beyond called an interoperability, but federer
anything with communities, with organization and with collectives.
This great, radically different ways of working, but also thinking in terms of sustainability,
economic sustainability.
And bonfire exists within this web of alliances, each of them bring in different kinds
of expertise and each shaping what and how we build together.
Those are some examples, so we are working with the cluster and metadata here.
Both on hosting and on interoperating, they're a loud open source calendar, community
calendar.
And cop cloud, which created it's our Federation of Collective and Cooperative doing hosting
and currently Abra, the tool that they created, is the preferred way of installing bonfire.
And newsmask, which is our UK Foundation, and they developed native application that works
both for iOS and for Android, specific for communities.
So basically, we are creating, we are extending bonfire to provide the APIs so that
an app build with the newsmask can plug into bonfires that can.
So any communities can benefit from having bonfires that can.
And this also implies that when a community reach out to newsmask for a specific features,
we coordinate, we build the features on the bonfire backend and provide the APIs so that
they can only have to implement on the front end on their native application.
And just wrap the, what this ecology enable, we have currently two pilot, two project
that we are starting working together.
The first is Jacobine, the German edition, is a political magazine with more than 100,000 subscribers.
And they wanted a community platform that wasn't as should be able, they could control,
they could organize events, but also have discussion in pools, and totally control the platform.
And tightly integrated with their publishing platform.
So up to you.
Yeah, another example is a small town in the Southwest England called Top Ness.
And so they have a news website, a local journalism, and they also list local events,
everything that's happening in the town on that website.
So a lot of people go there, but for anything social, they go to Facebook groups.
And a lot of people are still on Facebook only to participate in those groups.
They would love to delete their account, but they're stuck.
And so we're working together to launch an app with newsmask, a powered by bonfire on the web.
And the co-op cloud and class in the method of hosting all together.
And it will be a taught Ness app, which is the name of the town.
So people are not signing up to the Fediver signing up to this weird thing.
They just download the town's app, and they get access to news, events, and a community.
So here's a little demo of how that works.
So with the Louty community calendar, an event organizer can input an event.
And then that appears on Louty as an event in their calendar, but also gets pushed to bonfire.
Thanks to the activity pub client to server API event mentioned.
So that sort of medically becomes federated and social, where it can be reshared.
You can comment on it.
And then it also appears in the mobile app.
So that's it.
We tried to keep it short to leave room for questions.
If this resonates with you, please get involved, try out bonfire, fork it, create an extension.
And talk to us if you want to form new alliances or bridges.
So I'll just end with a quote from Annette Singh, as contamination changes world-making
projects, mutual worlds, and new directions may emerge.
Everyone carries a history of contamination.
The reality is not an option.
One value of keeping precarity in mind is that it makes us remember that changing with circumstances
is the stuff of survival.
Thank you.
We also have a crowdfunding up if you're interested in supporting what we're doing.
Thank you.
Any questions?
Yes, we put a lot of focus and time into interoperability.
This approach of wanting to support any type of activity and content.
It means, first of all, that we are able to display content coming from all those platforms
and interact with it.
And then that anything we create, we find a way to make that compatible with them in some
cases.
It means working with the standards community to like clarify or improve or build upon
the standards.
In some cases, it's talking directly with other implementers and coming up with an agreement.
And in many cases, it's just using dirty work around.
So yeah, there's a lot of like packaging things up to look like a micro blog, even though
it's something else.
Just so it can be previewed and messed it on, for example.
But for now, the effort is more from other activity platform to bonfire, so that we
ensure that if a book review comes to bonfire, we are able to display as a book review
same for events and others.
So it's more an effort on our side as the beginning.
I'm assuming it's not too much effort to generate a new community of the interface, the way
you have protagonists or protective bands.
And so I think probably part of your growth idea is to be able to create bonfire with
your faces for more different communities who want to use the platform.
And I like this because it's like the discourse forms off there, something that I think
allows us to look so all and runs down a lot when you want a platform.
That doesn't interrupt around a goal.
That's something that we all still kind of self-posed and it's self-community, right?
But it doesn't bridge.
It's not creating a content type that natively integrates the platform or activity
up.
I said, sort of what you're thinking is that you'll be able to create just more and more
compatible interfaces or additional communities.
And I'll just be familiar if you had a base and small customization to the end of the
audience.
Do you like that?
Yes.
I'm going to surprise the question.
Okay.
So you basically ask if our strategy for sustainability is to be able to grow by creating
specific flavor of bonfire for specific verticals like neighborhood or publishers or
others.
Yeah.
Actually, the best way to do that would be to partner like to do a lot of code design
in session with like specific use cases that would be hyperlogal community or publisher
etc.
And find like the 90% that they need.
And then yeah, later hopefully it would be like subterl customization on top of like
branding for the specific community.
Yeah.
And you also ask specifically about discourse.
Luckily there is an activity plug to plug in for discourse to make it better.
I don't know how well that works.
But there's also no BB which is similar form software that federates natively as well.
So we want to interrupt right with those.
So you're asking if circles are private things or you're asking if circles are private
things just for the person who creates them or not.
So by default they are private.
The initial intention of circles is a way to sort of categorize your contacts for yourself
so that when you create a post or a starter group you can decide who can see it, who can
join it, who can even edit it.
So it's a way to control sharing.
But there's also a way and that's opt in where you can share a circle in order to, for
example, if you have tried blue sky where they have starter packs.
It's like a list of people that you recommend to follow, for example, here are all the
post them speakers this year and you have a list and you can easily follow them out.
So you can use a circle for that but that's if you choose to share it and it doesn't
mean sharing it publicly.
You can also use circles to say I'm going to share this circle with these other circles.
We also had a demo of using a circle for setting boundaries but it didn't, it didn't
play and probably we will not play right now as well.
So, thanks very much.
Thank you.
Yeah.
So this is early days for that implementation.
Currently the focus is on like the technical parts of interoperating and the encryption
and key management so to make sure that's interoperable.
So, we haven't done much work on UX yet but the spec allows for going beyond just messaging
because it uses activity streams which is one part of activity pub where you can define
activities and objects so you can have a post but you can also have an event so you can have
lots of other JSON objects and a lot of metadata.
So the spec allows for putting that into the encrypted blob basically so you're not just
sending text messages, you're sending rich data so you can imagine the future like a can
ban tool or something that is into an encrypted with your team.
Okay.
Hopefully, yeah.
Yeah.
And I wonder, you haven't mentioned you necessarily vary the words as you have faverm or
faverm or plugin which kind of copies research gate and those to be tools for scientific
communities like articles may be discussion about this maybe even peering rules and I wanted to ask you
what are the plans and what challenges did you have while thinking about this.
Yeah, the super interesting question because I think also there is maybe we didn't
the great job to explain but on the open science network it was a bonfire initiative
but rather a scientific collective that came to us saying we want to use bonfire for our
scientific collective, but we would really love if on top of bonfire we could have the
or city integration or we would be able to share directly paper but having proper metadata
so not just link preview but also the research journal and other kind of metadata
the status of the paper and so on.
So we started prototyping these features with them and then we basically only share openly
what we were doing and other scientists started to discuss with us and the idea is that
specifically the open science flavor should be really driven by the scientific community
driven not only in terms of the roadmap in terms of the sustainability in terms of the governance
and everything like potentially also the future developments should be developed in collaboration
or they should figure out because I think it's one of the most sensitive and important topic
that we can do right now.
So you're asking if people from outside bonfire instance where a circle is defined can also interact
with that circle or like post to the circle address it now that's not the intention of circles
some people are asking that so we might have to explore that but we think that groups are better
answer to that need and so that's the next project that we're going to work on after
and to an encryption here.