As an alternative to using large, monolithic browsers based on WebKit2 or Blink, I think the best option would be to leverage Haiku features to make less generalized browsing and communicating options for the internet.
I’ll start with a list of examples:
Forum browser (like Tapatalk but open source)
Instant messenger (Chat-o-Matic)
Video conferencing (Jitsi Meet is an open-source Zoom replacement)
More native apps for web-based stuff would be great.
I must admit that some days Firefox is the only application I use,but if native apps are well-made,integrate good with the OS and are lightweight while still providing the necessary functionality,I’m happy to leave those stupid webapps behind.
About your list…
Great idea,I also like forums,but unfortunately they don’t have standardized API endpoints or feature sets,some are even just server-rendered webpages without any API at all,where you’d have to dig through the HTML source to grab the contents.
I wonder why the good old Usenet isn’t used more.It’s basically a forum based on a standardized protocol for which native clients exist for most platforms.There’s even a native one for Haiku,but it doesn’t work currently and hasn’t been updated for a long time.
The situation for messengers is nearly as difficult as for forums.There are thousands of chat protocols out there,they have different feature sets and work in very different ways.It’s not easy to make them all work perfectly fine in a single unified chat application.
Chat-O-Matic is a good point to get started here,however.It seems to bring most functionality that a basic group chat expects.What I’d really love to see supported is the Matrix protocol.It’s used very much these days and it brings connections to hundreds of other protocols through its bridges.
Better forget about Jitsi when it comes to native applications.Yes,it’s open-source,but I really doubt that it’s easy to write a native application around that Javascript thingy.There are native video conferencing solutions already,like the Tox protocol (for example implemented in qTox based on Qt) or Jami (GTK+,don’t know if it works on Haiku).
Then you still need support for Webcams to make this work,however.But I like the idea.Maybe some day it will happen.
Don’t know anything about CRMs so I leave that out
That already works perfectly fine in VLC which you can find in HaikuDepot.I also think that it’s probably not a big deal to add this functionality to native apps,too.
Additionally,I’d like to see an application like NewPipe (Android) for Haiku,where you can watch and download Youtube stuff in a native app,without ads and with tracking minimized to as few as possible.Can be based on youtube-dl to get the actual video URLs.
From another reply: The Gemini protocol.I also like it and it’s not that difficult to write a native app for it due to it’s very limited feature-set.I’d really love to see that happen.There are a few ported Gemini browsers already,but they all don’t integrate that well with the Haiku UI and are not much fun to use here.
Maybe we’ll see some more native apps soon?That would be great.But I wouldn’t say that it’s easier than maintaining one single webbrowser.Instead you now have to maintain dozens of small apps,give them updates regularly and make sure they stay compatible with future versions of the servers.And,of course,reimplement all that stuff for which web-based clients already exist and get maintained by others.
And then we still need a good webbrowser because it’s impossible to bring all of the web into its own application and there are many cases where it simply wouldn’t make sense.
I really wouldn’t say that it makes anything easier,but of course more fun to use.
You are overlooking a considerable amount of applications or proprietary services that either don’t have an app or it’s not open source or there isn’t a public API available.
Miro, RemNotes, Notion, Teams, Office online, Lark Suite are just a few examples.
How do your ideas fit into this complex ecosystem of applications?
How is the average user supposed to use them if a native app is not available? Ergo we need a browser, period.
We just can’t ignore this aspect. The web is what it is and moved from the simple hypertext and resource browsing to a rich ecosystem of interactive applications.
Reg #1, there is actually a standard forum API that could be utilized - the one provided by Tapatalk (but it requires the plugin to be installed on the forum server).
I wrote a Tapatalk client in C# / gtk-sharp for Linux years ago using xml-rpc and it was quite straightforward. However, after a few years it seems a new version of the server plugin broke the API I had used. Also, although Tapatalk provided the API, they seemed to change the usage terms later on and tried to take down any app designed for mobile devices… Not sure what is the current status of their terms / API, but I will try to get updated on this.
there’s a strange almost cult ish authoritarian need to control everything from tech companies, it is highly corrosive.
I’m sure it’s coming from kegal misinterpreting share holder liability issues. anyways we are stuck with the diarrhea soup sandwhich and a fork. a lot of what people are doing on phones is using apps. most Facebook messenger users are using the app, same with Facebook, twitter etc
No but the apps are developed and owned by the company (Meta, for example). There is no chance, at least at the moment that Meta, Miro, Notion, and more would be interested in Haiku. So you’ll cut out all the users of these platforms.
Or have I misunderstood the point?
Closed source apps like FaceBook are the respective properties of Meta and are rumored to contain loads of spyware that the company uses to sell to its advertisers. Windows 10+ does the same as do the Google apps on Android.
I’d prefer an option based on MediaKit and Translators used to drive the protocols. Once on open-source option like Mastedon is done, there will be an open source example for others to follow if they so choose.
Tapatalk is closed source so using its plugins for an app might not be a good example. Discourse uses an elaborate client separate from its backend. If it weren’t written in Javascript it would be a classic example.
If it was any good… as it stands it’s a pretty bad client. Especially because it wants to be so web3.0 and meddles with browser features that would have worked much better if left alone.
(for example, replacing emoticons with bad smiley pictograms while basically every OS has an emoji keyboard. breaking the text cursor on iOS. Funny how all of this works on trac.)
I was actually referring to Discourse, not Tapatalk, in the quoted sentence. Unlike Tapatalk, Discourse is fully open-source but is written in Ember.js for the client side. I’m looking through the data portion of the Ember.js source code to see how hard it would be to translate the JavaScript into C++ on the client side.
Update
Discourse has a ReST interface. See the documentation.
I’m unclear of what your goal is. To conduct such an analysis you need to determine a population and a sample. Yet the Haiku user base is not a representative sample and we don’t have such an information, AFAIK.
If you just want to know how many users browse the Internet to access specific social media services, here you can find it. You are still missing those who use the service exclusively via native mobile apps, i.e. via their API.
Are you anticipating that the user percentage is negligible?
If we wanted to have posts to the ticket website for bugs related to WebPositive from within Haiku when it cannot be accessed from WebPositive when it messes up, a ReST interfaced app using a native frontend would be one way to do it. Also, when accessing this forum from within Haiku if WebPositive’s build becomes unstable, a similar app could be useful for this as well. The only question is whether it would be practical or not.
It seems to be open-source but the GUI seems to use a web-frontend even on the local versions. I’d like to be proven wrong but their server doesn’t seem to have a ReST interface at all. Do you know what protocol the communication with the server is?
Update
I looked at the files in the package for the desktop version in Manjaro Linux. Chrome-Sandbox is one of the files included by its installation. All it does is wrap the web version locally.