Punch nazis, trebuchet TERFs.

I am building Voyager, a client for lemmy!


I mainly post under @aeharding@vger.social now.

  • 1 Post
  • 73 Comments
Joined 2 years ago
cake
Cake day: June 13th, 2023

help-circle
  • aeharding@lemmy.worldtoTechnology@lemmy.world*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    9 months ago

    Mlem in app browser is using an in app browser API that is secure by design. It doesn’t allow snooping or injecting anything. This article is talking about abusive apps like Facebook that roll their own in app browser.

    Edit: although on iOS, the secure iOS in app browser api is always using safari engine, so the user choice argument is still valid.


  • It’s crazy that the in-app browser isn’t an OS-level overlay that the app can’t influence or look at what the user is doing in it.

    Android and iOS both have apis for in app browsers that are secure by design. Voyager for Lemmy uses this. Mastodon uses this. Last I checked even Twitter used this. However Facebook does not.

    these platforms also offer lower level APIs to build custom interface which are more powerful and flexible (but can be abused). This isn’t necessarily a problem. Custom browser apps need that functionality, and apps sometimes display their own content with web views.

    The problem is that app stores allow slapping a skin on this more powerful API and treating it like an in app browser to connect to arbitrary sites. Dumb imo. If you offer an in app browser, it should be required to use the platforms secure in app browser API.

    More powerful APIs should only be available to browser apps and displaying your own content in a web view.








  • There are absolutely reasons where a native app is worth it - I just don’t think building your own backend or not factors into that decision much.

    Maybe the point you are trying to make, is when you have enough resources/large enough company, having duplicate teams for each native app isn’t that big of a deal? I agree financially, although is is harder to technically coordinate two teams with dual releases and implementing features twice, with twice the bugs, and it slows things down. (Maybe not a big deal to Bitwarden - their app featureset may be quite stable, IDK)

    (Disclaimer - I’ve been on teams building kotlin/swift apps and also cross platform apps professionally, so this is my firsthand anecdotal experience.)








  • Yeah, this. Remark, the markdown library Voyager uses, is very powerful but also extremely complex (it has to be, to deal with Markdown edge cases).

    I made a bit of progress last week on a custom plugin but it’s a lot of work. There’s like 4 layers of parsing required.

    I wish Lemmy used GFM spoilers, which just uses normal details and summary html tags. But alas.

    It’s really annoying there’s no standard markdown syntax in common mark.