Because outsourcing your core business processes is a bad idea. A fediverse app that relies on a library to do all the fediverse stuff is going to have a bad time. Not straight away, but eventually.
tofu@lemmy.nocturnal.garden
on 14 Apr 07:06
nextcollapse
I’m not sure about that. Sometimes it’s more about properly applying libraries. Thinking of database handling or cryptography
Imagine you want to write a competitor to PostgreSQL and you start out by importing SQLite into your project and building on top of that. To you it seems like a good idea because you've never written a DB app before and the only DB you've ever seen before is SQLite. You'll get a prototype real fast but you'll never build a PostgreSQL equivalent because you never learned the foundational knowledge of how a DB works and because SQLite forecloses all the pathways you need to get there.
Same thing.
sorrybookbroke@sh.itjust.works
on 14 Apr 08:05
nextcollapse
I’d argue this is more like “I want to build a competitor to spotify so let’s decide between using mariaDB or writing an SQL compliant database from scratch”
In your example, a database is the end goal and you can either start with a premade or make your own.
Here, a social media platform is the end goal. Activitypub is a very important part of it but it’s not the entire piece.
If we replace the parts of your analogy with the original your example would parse out to “I want to make a competitor to lemmies ActivityPub integration, so let’s start with fedify” which is not the same as the article states.
Now, should you re-impliment a protocol yourself or use a generic library is the real question. Both have their benefits. With option A you have full code ownership and can wrap your solution around your end goal without the issue of dealing with the original to get needed changes accepted. You don’t have to worry about code not written by or understood by you. With option B, you get a more robust and almost certainly more accurate implementation. Along with, for free, better integration with any service using the same library. Very useful for a federated service when talking about cross platform.
Both have many more positives and negatives of course and each person should decide on their own how to proceed.
My opinion? I think it’s usually best to own anything which could feasibly be understood by a single dev. Even if each dev doesn’t. Anything larger shouldn’t be internal in my strong opinion unless very good, specific reasons apply that makes an external solution impossible or increadibly difficult. Most negatives of an external library also apply at that point with enough time.
Jesus_666@lemmy.world
on 14 Apr 08:21
nextcollapse
Of course you wouldn’t use an existing database engine as the foundation of a new database engine. But you would use an existing database engine as the foundation of an ERP software, which is a vastly different use case even if the software does spend a lot of time dealing with data.
If I want to build an application I don’t want to reimplement everything. That’s what middleware is for. The use case of my application is most likely not to speak a certain protocol; the protocol is just the means to what I actually want to do. There’s no reason for me to roll my own implementation from scratch and keep up with current developments except if I’m unhappy with all current implementations of that protocol.
Of course one can overdo it with middleware (the JS world is rife with this) but implementing a communication protocol is one of the classic cases where it makes sense.
tofu@lemmy.nocturnal.garden
on 14 Apr 09:05
nextcollapse
Not same thing. I’m not talking about a postgres competitor. The other two replies already phrased it pretty good IMHO. I don’t think that, when building a fedi app, impending AP is the core of your app.
It looks like an open source project. Makes a hell of a lot more sense to implement using that than rolling your own? If it’s missing something you need, write it for them.
Writing your own implementation is extremely unlikely to differentiate your app/product. There is a spec, either you implement it and it works, or you don’t and it doesn’t. Using a maintained library is by far the better option.
Focus your time on the product you are building not the tech.
mutual_ayed@sh.itjust.works
on 14 Apr 13:43
collapse
The Allure of the Fediverse and the Challenges of ActivityPub Implementation
The fediverse—a decentralized social web powered by protocols like ActivityPub—is an exciting space to explore. If you’re considering building the next great federated app, connected to platforms like Mastodon, Lemmy, Pixelfed, and more, you might be tempted to implement ActivityPub from scratch. While this approach offers total control, it’s a daunting task due to the complexity of the standards involved.
The Challenge: Data Modeling with ActivityStreams & JSON-LD
At its core, ActivityPub relies on ActivityStreams 2.0 vocabulary and JSON-LD syntax. This combination introduces significant complexity:
Understanding ActivityStreams Vocabulary:
You need to model actions and objects (e.g., posts as Note or Article, profiles as Person or Organization, and actions like Create, Follow, Like, Announce) using the precise terms defined in the specification.
JSON-LD Specifics:
JSON-LD has unique rules that complicate direct JSON manipulation:
Missing vs. Empty Arrays: A property being absent is often semantically identical to it being present with an empty array.
// No name property
{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
// Equivalent to:
{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "name": [], "content": "…"}
Single Value vs. Array: A property can hold a single value or an array.
// Single value
{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
// Equivalent to:
{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": ["Hello"]}
Object References vs. Embedded Objects: Properties can contain either embedded objects or URI references.
threaded - newest
Because outsourcing your core business processes is a bad idea. A fediverse app that relies on a library to do all the fediverse stuff is going to have a bad time. Not straight away, but eventually.
I’m not sure about that. Sometimes it’s more about properly applying libraries. Thinking of database handling or cryptography
Imagine you want to write a competitor to PostgreSQL and you start out by importing SQLite into your project and building on top of that. To you it seems like a good idea because you've never written a DB app before and the only DB you've ever seen before is SQLite. You'll get a prototype real fast but you'll never build a PostgreSQL equivalent because you never learned the foundational knowledge of how a DB works and because SQLite forecloses all the pathways you need to get there.
Same thing.
I’d argue this is more like “I want to build a competitor to spotify so let’s decide between using mariaDB or writing an SQL compliant database from scratch”
In your example, a database is the end goal and you can either start with a premade or make your own.
Here, a social media platform is the end goal. Activitypub is a very important part of it but it’s not the entire piece.
If we replace the parts of your analogy with the original your example would parse out to “I want to make a competitor to lemmies ActivityPub integration, so let’s start with fedify” which is not the same as the article states.
Now, should you re-impliment a protocol yourself or use a generic library is the real question. Both have their benefits. With option A you have full code ownership and can wrap your solution around your end goal without the issue of dealing with the original to get needed changes accepted. You don’t have to worry about code not written by or understood by you. With option B, you get a more robust and almost certainly more accurate implementation. Along with, for free, better integration with any service using the same library. Very useful for a federated service when talking about cross platform.
Both have many more positives and negatives of course and each person should decide on their own how to proceed.
My opinion? I think it’s usually best to own anything which could feasibly be understood by a single dev. Even if each dev doesn’t. Anything larger shouldn’t be internal in my strong opinion unless very good, specific reasons apply that makes an external solution impossible or increadibly difficult. Most negatives of an external library also apply at that point with enough time.
Of course you wouldn’t use an existing database engine as the foundation of a new database engine. But you would use an existing database engine as the foundation of an ERP software, which is a vastly different use case even if the software does spend a lot of time dealing with data.
If I want to build an application I don’t want to reimplement everything. That’s what middleware is for. The use case of my application is most likely not to speak a certain protocol; the protocol is just the means to what I actually want to do. There’s no reason for me to roll my own implementation from scratch and keep up with current developments except if I’m unhappy with all current implementations of that protocol.
Of course one can overdo it with middleware (the JS world is rife with this) but implementing a communication protocol is one of the classic cases where it makes sense.
Not same thing. I’m not talking about a postgres competitor. The other two replies already phrased it pretty good IMHO. I don’t think that, when building a fedi app, impending AP is the core of your app.
That’s a complete apple/oranges comparison. Fedify is an application framework.
Try “Imagine you want to write a competitor to {Mastodon/PixelFed/Lemmy/PieFed/Pleroma/WriteFreely}”, and see where your analogy takes you.
It looks like an open source project. Makes a hell of a lot more sense to implement using that than rolling your own? If it’s missing something you need, write it for them.
Writing your own implementation is extremely unlikely to differentiate your app/product. There is a spec, either you implement it and it works, or you don’t and it doesn’t. Using a maintained library is by far the better option.
Focus your time on the product you are building not the tech.
Holy wall of text, Batman!
The Allure of the Fediverse and the Challenges of ActivityPub Implementation
The fediverse—a decentralized social web powered by protocols like ActivityPub—is an exciting space to explore. If you’re considering building the next great federated app, connected to platforms like Mastodon, Lemmy, Pixelfed, and more, you might be tempted to implement ActivityPub from scratch. While this approach offers total control, it’s a daunting task due to the complexity of the standards involved.
The Challenge: Data Modeling with ActivityStreams & JSON-LD
At its core, ActivityPub relies on ActivityStreams 2.0 vocabulary and JSON-LD syntax. This combination introduces significant complexity:
Understanding ActivityStreams Vocabulary:
You need to model actions and objects (e.g., posts as
NoteorArticle, profiles asPersonorOrganization, and actions likeCreate,Follow,Like,Announce) using the precise terms defined in the specification.JSON-LD Specifics:
JSON-LD has unique rules that complicate direct JSON manipulation:
// No name property { "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"} // Equivalent to: { "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "name": [], "content": "…"}// Single value { "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"} // Equivalent to: { "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": ["Hello"]}// Embedded object { "@context": "https://www.w3.org/ns/activitystreams", "type": "Announce", "actor": { "type": "Person", "id": "http://sally.example.orgBecause you don’t use Typescript/JS perhaps?