@xnx PieFed won’t have an app any time soon due to the way it’s implemented. It’s still awesome without a native app because it’s fast and doesn’t really need direct access to hardware to do its thing.
Tech detail: PieFed is a Python app using Flask and server-side rendered HTML templates. It is super fast as there’s no heavy Javascript framework being used. The maintainer has written about how PieFed is developed with poor internet connections in mind: https://piefed.social/post/6102
@skullgiver Good Q. Some thoughts… a standard Python, Flask, PostgreSQL app can handle hundreds of requests per second on a single machine. Any bottlenecks - Lemmy or PieFed - would probably not be at the language yet. For example, Lemmy’s poor performance when I looked ~1 year ago came from a bizarre disregard for things like relational DB query optimisation, HTTP caching, and how the stock frontend lemmy-ui fetched data. Yet Lemmy is written in Rust which is known for speed.
There isn’t anything stopping this. It’s just that no one is working on an app. And there isn’t any API implemented (yet) for an app to hook in to and fetch posts and comments. Both could be programmed. Someone could also copy the Lemmy API and use arbitrary Lemmy apps with Piefed. I think the developer is open to any of that and I’m pretty sure I read some feature request. It’s just that the focus currently is on other things. And Piefed works well as an progressive web app. You can open it in your browser and click “Add to home screen” and you’ll get an icon and a browser window that pretty much feels like an app. I’m using that and also don’t see any benefit in putting in the effort to maintain an app, when it works well as is.
Both could be programmed. Someone could also copy the Lemmy API and use arbitrary Lemmy apps with Piefed.
This seems like an interesting idea. On one hand, I could see how it could hamper development, but on the other hand, it would be nice if all of the threadiverse platforms (Lemmy, Piefed, Sublinks, Mbin?) were standardized enough that the apps could be interoperable. I think giving users multiple options for how to access and interact with the content would be good for the fediverse as a whole.
That would be nice. In practice, not even ActivityPub as the underlying protocol is standardized enough to ensure interoperability between the microblogging, threaded conversations, videos, etc. As far as I understand, it’s pretty minimal and even voting etc isn’t as standardized as it needed to be. So I don’t have much hope for another protocol being that well-defined and agreed upon, if we don’t even have that.
That being said… ActivityPub defines server to server and client to server communication. I think a good way to tacke this is do away with extra Lemmy, Piefed, Mastodon and Peertube clients/apps, and have all the apps speak ActivityPub with the servers/instances. That’s already implemented on the server side. It’d do away with implementing any extra APIs. And make any app compatible with any Fediverse project. But we need a new ActivityPub protocol revision for that. Well-defined and with quite some extras. compared to what we have now. And everyone needs to agree on this and implement it. But in my eyes that would solve a lot of issues that are currently slowing down the Fediverse.
@threelonmusketeers@hendrik This is how many Fediverse microblogging systems currently work; they serve the Mastodon API for client to server (e.g. app to server) interactions. GoToSocial doesn’t even provide any user interface; you use it from some app originally designed for Mastodon. Why? I think because Mastodon’s HTTP API is simpler, better documented and well-tested compared to something like ActivityPub’s Client-To-Server API.
@xnx PieFed won’t have an app any time soon due to the way it’s implemented. It’s still awesome without a native app because it’s fast and doesn’t really need direct access to hardware to do its thing.
Tech detail: PieFed is a Python app using Flask and server-side rendered HTML templates. It is super fast as there’s no heavy Javascript framework being used. The maintainer has written about how PieFed is developed with poor internet connections in mind: https://piefed.social/post/6102
@fediverse
The only thing piefed needs for an app is a flask rest framework. It’d not hard
Any chance you will be able to help develop that?
I could but sadly I’ve got my hands full with my other projects atm.
Can you link to the GH issues?
There is none yet. They use codeberg not github btw
Heres an issue on lemmy api compatibility. They got far enough so some Lemmy apps already sorta work but it hasnt been completed https://codeberg.org/rimu/pyfedi/issues/13#issuecomment-1814982
Heres an issue on allowing the website to be isntalled as a PWA but help is needed on the iOS front https://codeberg.org/rimu/pyfedi/issues/179
deleted by creator
@skullgiver Good Q. Some thoughts… a standard Python, Flask, PostgreSQL app can handle hundreds of requests per second on a single machine. Any bottlenecks - Lemmy or PieFed - would probably not be at the language yet. For example, Lemmy’s poor performance when I looked ~1 year ago came from a bizarre disregard for things like relational DB query optimisation, HTTP caching, and how the stock frontend lemmy-ui fetched data. Yet Lemmy is written in Rust which is known for speed.
@fediverse
Why is that? They seem pretty similar on the surface, so I’m curious differences exist under the hood which would preclude app development.
There isn’t anything stopping this. It’s just that no one is working on an app. And there isn’t any API implemented (yet) for an app to hook in to and fetch posts and comments. Both could be programmed. Someone could also copy the Lemmy API and use arbitrary Lemmy apps with Piefed. I think the developer is open to any of that and I’m pretty sure I read some feature request. It’s just that the focus currently is on other things. And Piefed works well as an progressive web app. You can open it in your browser and click “Add to home screen” and you’ll get an icon and a browser window that pretty much feels like an app. I’m using that and also don’t see any benefit in putting in the effort to maintain an app, when it works well as is.
This seems like an interesting idea. On one hand, I could see how it could hamper development, but on the other hand, it would be nice if all of the threadiverse platforms (Lemmy, Piefed, Sublinks, Mbin?) were standardized enough that the apps could be interoperable. I think giving users multiple options for how to access and interact with the content would be good for the fediverse as a whole.
That would be nice. In practice, not even ActivityPub as the underlying protocol is standardized enough to ensure interoperability between the microblogging, threaded conversations, videos, etc. As far as I understand, it’s pretty minimal and even voting etc isn’t as standardized as it needed to be. So I don’t have much hope for another protocol being that well-defined and agreed upon, if we don’t even have that.
That being said… ActivityPub defines server to server and client to server communication. I think a good way to tacke this is do away with extra Lemmy, Piefed, Mastodon and Peertube clients/apps, and have all the apps speak ActivityPub with the servers/instances. That’s already implemented on the server side. It’d do away with implementing any extra APIs. And make any app compatible with any Fediverse project. But we need a new ActivityPub protocol revision for that. Well-defined and with quite some extras. compared to what we have now. And everyone needs to agree on this and implement it. But in my eyes that would solve a lot of issues that are currently slowing down the Fediverse.
@threelonmusketeers @hendrik This is how many Fediverse microblogging systems currently work; they serve the Mastodon API for client to server (e.g. app to server) interactions. GoToSocial doesn’t even provide any user interface; you use it from some app originally designed for Mastodon. Why? I think because Mastodon’s HTTP API is simpler, better documented and well-tested compared to something like ActivityPub’s Client-To-Server API.
@fediverse