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.
@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: https://socialhub.activitypub.rocks/t/event-sourcing-the-activitypub-server/972
@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.
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.
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".
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: https://complexevents.com/2020/03/24/event-driven-architecture-is-suddenly-popular-will-stream-analytics-be-next/
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.
"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.
@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.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.