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 10 points 3 weeks ago (5 children)

I'm not sure about that. Sometimes it's more about properly applying libraries. Thinking of database handling or cryptography

[–] rimu@piefed.social 6 points 3 weeks ago (4 children)

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 12 points 3 weeks ago* (last edited 3 weeks ago)

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.

load more comments (3 replies)

load more comments (4 replies)