Hello, this is the official account for flockingbird.

We are building a professional social network (think: LinkedIn) for the fediverse.

Here, we'll post occasional updates and pointers to where we are at. And we'll try to answer questions about the project.

Account is operated by @berkes so feel free to cc that.

Nice to have you with us! New here? Start with following some tags and people! Go check out public stream on your server to find some. Keep adding more people and tags, you can always unfollow something you don't want later.

Also do share your own stuff - write posts, upload images and add relevant tags so similar-minded people can easily find it. Consider filling out your profile as well, no personal data required. Any questions? Don't hesitate to ask, we are here to help.

Have fun on the network! :)

@flockingbird @berkes Welcome! I'm looking forward to checking out your site!

@flockingbird @berkes If you’d like to build this 10x faster you should fork Pleroma and create a new frontend for it.


Working like crazy.

Purchasing and developing land jumped to the top of the personal list. We're looking at building bungalow style housing because we have far more people to accommodate than originally thought. (Some of our friends in the southwest have had their business fall through and we're trying to absorb the overflow.) Gonna be pinching some pennies to make all that work.

@moth That’s awesome! Sounds like a nice path to freedom. Gonna grow your own food? 😛

I’ve just been working hard on fediverse stuff. Hit a milestone for Soapbox FE and gonna get back into the hosting service soon. Glad to see you here again, I was wondering.

@alex @flockingbird @berkes The greatest benefit to using Pleroma code is how well built it is for the long term, especially with how it takes advantage of the ability of Elixir to create lightweight yet scalable applications.

@alex @berkes @flockingbird Like I’m not gonna lie, looking at Pleroma code has helped me a lot with understanding Elixir and building Rosacon.

@alex Thanks for the suggestion!

Mastodon, kibou, pleroma etc. are built quite hard around things we don't need, yet lacks the things we do need.

We don't need toots, likes, replies and everything around it. We do need our own AP objects (Experience, ContactDetail, Relationship, etc) and activities. Quick PoC with mastodon and pleroma showed that it's quite probably going to cost more in "fighting defaults" than it wins in "reusing stuff".

Here's some of my thoughts:

@flockingbird Interesting. The idea of event sourcing is new to me, but at a glance it sounds similar to what Pleroma already does.

Pleroma has only two “hard” types, Activities and Objects. I suggest taking a closer look, because there’s no limitations on what types of activities it can send or receive.

@curtis @alex Indeed, we're looking at such an architecture.

Quite probably Ruby (but not Rails), since that does allow reusing pieces and code from mastodon.

How would pleroma fit in this? Does it offer pieces, libs or layers that I should reconsider as basis? My Elixir and Erlang is poor, so that would slow down initially, but if it fits well, certainly overcomeable.

@flockingbird @alex If resource usage and scalability are significant factors, then Elixir is the way to go.

I’m still trying to understand the long-term strategy, applications and benefits of your application, by reading.

If your applications are intended to be mainstream in the long term future, and will have an active open source support community, it would appear to be worth the investment to use Elixir and to re-use existing code like Pleroma.

@flockingbird @curtis @alex if you are smart language won’t be an issue Not an Activity Pub expert (not even novice) but I don’t think it would be a good idea to piece of code from Mastodon or other software without the whole app context. And an Activity Pub library tailored to everyone need will never exist

@duponin I'm sorry if I was unclear, but with "taking pieces of code" I wasn't implying we start to copy-paste randomly.

Just pieces and lower-level stuff, like webfinger, AP-signature handling, avatar/media federation and such, that are part of mastodon-monolyth, but which would cost a new implementation loads of time to build from scratch.

Even if the code cannot be used verbatim, the ideas and concepts can still be "copied".

@flockingbird @alex


Event driven architecture use cases

Event-driven architecture (EDA) has suddenly become a hot topic among software architects, after almost three decades of sitting on the back burner. There was an initial wave of interest in EDA when message-oriented middleware (MOM), including publish-and-subscribe (pub/sub) messaging systems, emerged in the late 1980s and early 1990s. But most application architecture continued to center on batch processing and synchronous, client/server (request/reply) design patterns, such as service-oriented architecture and its recurring facelifts (microservices and APIs). Sure, some advanced organizations deployed message buses and implemented event-driven applications in the intervening decades, but EDA remained underutilized in most mainstream IT departments until now.

This seems to be changing, driven by business demands for more flexible, easier-to-change, loosely-coupled applications, and enabled by a new generation of high performance, pub/sub messaging infrastructure products, including Kafka, Kinesis, Pulsar, NATS Streaming, Solace, Azure Event Hub and numerous other subsystems. There has been a widespread awakening to the benefits of EDA for increasing the scalability and agility of business systems. We have recently seen some excellent articles that explain the mechanics and benefits of EDA from sources including Amazon, Confluent and Solace.

But there is a second important aspect of event processing, something related to EDA but actually different in many respects. We are referring to the use of event data in stream analytics to provide real-time or near-real-time intelligence. Stream analytics is based on the mathematics of complex-event processing (CEP). CEP is a computing technique in which incoming data about what is happening (event data) is processed as it arrives (data in motion or recently in motion) to generate higher level, more useful, summary information (complex events). Complex events are computed through aggregation (e.g., count of how many times “Coronavirus” has been tweeted in the past 10 minutes) or pattern detection (e.g., is this sequence of financial transactions likely to be fraudulent?). One complex event may be the result of calculations performed on a few or on millions of base (input) events from one or more event sources.

@curtis I'm not sure if I'm following you along here :D

I've been doing event-sourced systems for almost 10 years now (webhosting/provisioning, payment systems, ecommerce, blockchain and now bookkeeping systems), but I'm certainly not familiar with the CS parts of it -being self-taught-.

Do I understand you right when you imply ActivityPub within an event-sourced setup is not a good match? If so, what would be the main reason?

@curtis Now I'm completely lost 😂

I was referring to the article with which you replied: Source:

It could be that I'm missing a reply somewhere due to the infamous "ghost replies"-AP issue. Maybe that is what is confusing me; because I am missing some context as to why you replied with that article.

@flockingbird OK, I didn’t mean to imply that ActivityPub would not be appropriate for your solutions. I’m simply trying to understand the use cases and application areas of event driven architecture. No other agenda.

@flockingbird @berkes What do you plan to do about anime titties federating to your serious business network?

@brother @berkes Nothing at all. This is up to the people running an instance.

"professional, work related" means different things to different people.

Though the issue is somewhat mitigated b/c we focus on your profile and don't have "toots" or "status updates"; the one thing people consistenly mention they "dislike" about LinkedIn as well.

@flockingbird @berkes Fair enough, you've actually got an answer for that question which is more than Moodle had lol

@flockingbird Good luck! Happy to chat about funding opptys for your project (I have experience via @lightmeter), business models, and network effects.

@samtuke That is a very welcome offer, certainly!

We're currently restructuring internally a little; the person in charge of business and marketing is focusing on other projects as of this summer, so that leaves a large gap there.

Finance is not a big issue -yet- but getting the businesscase (and therefore the longevity of the open source software) right, is something we really could use help with! Will get back to you in a PM when time arrives.

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.