Lots of options here TBH and I haven’t put much thought into it. Providing a service by running and managing software updates, migrations etc…, is one. MongoDB Atlas and Confluent Cloud are good examples of what I had in mind.
Why do people hate the “as a service” model?
The “as a service” business model is interesting. It may be a good funding path for mastodon, lemmy devs etc…
I see. I don’t know much about authorized fetch, I’ll have to investigate a bit (I’m able to follow the linked account from mastodon however).
I was able to find greg_channel@flipboard.video on this instance for example, a wild guess was that maybe lemmy expects peertube « communities » to have the « channel » string in the name but it’s unlikely 😂
Tried to follow the dot_social@flipboard.video channel from Lemmy but it doesn’t show up.
Shouldn’t it contain the « channel » string in the name ? :/
I don’t know how I’d feel about following users from Lemmy TBH. It’d feel like trying to compete with Mastodon or other microblogging platforms and I’m not sure we need it in this space.
I’d find it interesting to have a unique identity for services in the fediverse instead.
More privacy and less profit 🫣
I realize most people could rather not pay for a service they currently have for free (which is partly due to the lack of transparency regarding our data usage).
I’d pick JavaScript, mostly because of the ecosystem (even though we could argue about this point 😅)
I’d love to give Rust a try however I don’t have much time nor want to dedicate to coding in my spare time!
I believe part of what makes the VS Code experience is the extension store. Is this managed in some way with this distributed flavor ?
Right. I suppose the things people don’t like in traditional social media are different and we’re probably here for different reasons.
IMO ephemeral posts are interesting also because everything may not be worth archiving (and hence increase the overall impact of social media storage), I get it that we can have divergent views on this.
If you don’t mind the runtime overhead OpenTelemetry would do the job (with maybe some sort of manual instrumentation for things like timers) and builds a service map.
IMO however if your services are closely tied together then how about grouping them together into one or multiple mono-repositories ? Or at least start designing your bounded contexts so that documenting by hand doesn’t become a maintenance burden.