Professional C# .NET developer, React and TypeScript hobbyist, proud Linux user, Godot enthusiast!

https://blog.fabioiotti.com/\ https://github.com/bruce965

  • 1 Post
  • 21 Comments
Joined 3 years ago
cake
Cake day: March 9th, 2022

help-circle
  • bruce965@lemmy.mltoBuyFromEU@feddit.orgAdios, Amazon Prime
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    1
    ·
    9 days ago

    I think so, but only on some devices. As far as I understand, you can only play in high resolution on devices which support stronger hardware DRM. On those devices recording the screen might be harder/impossible.

    I never tested this theory though, so please do not quote me on this.



  • I have to admit that I didn’t really think about reminders. That would perhaps make more sense for Simple Calendar, perhaps in the future I might consider linking notes and reminders. Or maybe it would make sense to implement it directly in Simple Notes? I don’t know, I’ll keep that in mind for later, thanks!

    the number of clicks/menus/presses it takes to create a note

    I strongly agree on that. It must be at most as many clicks as on Google Keep, i.e. two clicks (plus a few to open the app).

    import existing Keep notes from a Google Takeout into your Simple Notes

    I didn’t think about that. That shouldn’t be too hard. After the MVP (minimum viable product) will be ready, imports from various common formats should be implemented, and I guess Google Takeout for Google Keep should be supported too.

    Thanks for the suggestions!



  • use case is a shopping list for my SO and I. I want to be able to add stuff throughout the day, and cross them off once I grab them from the shelf, and separately be able to clear completed tasks

    Sorry for the late reply. Oh yes, that’s what I like about Google Keep, the collaborative aspect. What do you mean by separately be able to clear completed tasks”? Do you mean being able to do it from multiple devices which are synchronized in real-time?

    [Simple Chat] Why not just use one of the other Matrix clients?

    Yes, you have a point… let’s keep Simple Chat for later then. I had this idea of making an app for each of my needs and let them all connect to a single server with a single unified user. Good quality Matrix clients already exists, I guess there is no need to build a custom client for the chat if I end up adopting Matrix as the protocol.

    [Simple Docs] This seems overly ambitious.

    Let’s say that’s a longer term goal for the future. I might be underestimating the complexity of Google Docs, but if you think about it I would say it’s not much more than a rich-text editor. Basically it’s the same things as text notes, just with a bit more formatting options. I couldn’t say the same thing about Google Sheets and Google Present.

    No. Matrix is designed for chat, not data, and self-hosting it requires a fair amount of resources.

    Why do you think so? I have tried it and it seems to be as simple as any other server thanks to Docker. I have a script to launch it here (mirror). It seems to use 160MB of memory and about 1% of my CPU when idle. I haven’t done any serious tests though, maybe it wouldn’t scale as well as I think.

    I’d personally just DIY it since it’s really not a ton of logic

    Well… there must always be a protocol behind it, it can be as simple/specific or as complex/generic as you want, but there must always be an agreement of the format of data exchanged between client and server.

    By adopting the Matrix protocol, there wouldn’t be any need to write a custom server, because Matrix servers already exist.

    Matrix is designed for chat, not data

    What’s the difference between chat and data? A chat is a list of messages. A collaboratively-editable document is a list of changes. As far as I understand, Matrix uses “events” to describe things happening. When a user sends a message, the server emits and event like “add user X’s message Y to your list of received messages”. It shouldn’t be too different than emitting an event “replace text at position X with Y” every time a document changes. They even have ephemeral events for temporary state, such as “the user X is currently typing”. That should be similar to “the user X placed their cursor at position Y”.

    Do you think I might be oversimplifying or thinking it wrong?



  • Regarding multi platform targeting, have you considered something like React Native or Flutter

    I have! I use Flutter in a professional setting and I do not hate it, but I am madly in love with React (not Native) for my personal projects. I tried React Native in the past and I found it a bit finicky, but it was just a “brief encounter”, so I might change my mind about it in the future. For now I would go with Electron to save time, but I do not exclude the idea to build a desktop + mobile interface in Flutter in the future. React (not Native) can also run on any platform, that should be more than enough for the MVP.

    I absolutely do not want to go with Flutter for the web though, as I feel like it’s the exact opposite of what I would dream the web to be. I feel like Google built Flutter to give Android developers a tool to make apps with the excuse “oh yeah, it works on browsers too” and call it a day. Flutter basically bypasses most of the things that browsers do and in my personal opinion it re-implements everything more poorly than how a traditional web app would. Come on, they even built their own layout engine and even a rendering engine, was that really necessary? Browser extensions don’t integrate well with Flutter apps, and the debugging experience is subpar. I really like Flutter for Android and desktop apps, and I might even say it’s easier/simpler than Android Studio (Kotlin), but personally I feel like it’s just a big dirty hack in the web context.

    Okay, I just realized that my reply sounds a lot like a rant. My apologies. Please consider this as my current view on these tools, it might change in the future. It’s not a criticism.

    the company behind it shuts down or gets sold

    That’s an important concern. Well, the source code is AGPL 3.0, so there is no risk of it disappearing. Also, this would be my hobby project and I absolutely do not expect it to ever become anything commercial. I do not even plan to accept donations or anything like that. Basically it’s something that I need, and since it doesn’t exist I am considering building it myself.

    There is a big probability that I might stop working on it either because I find it “good enough” for my needs or because I won’t be able to work on it anymore, but I would say I’ll try to keep it as simple as possible, so it should be relatively easy to maintain. Also, relying on Element (Matrix) maintain the server code would mean I just need to maintain the client, which should cut the work down by 50%. I strongly hope Matrix will never shut down or get sold.

    In any case, okay! Let there be the possibility to export data in a common format! (Preferably Markdown)

    I feel all my data is siloed across several apps

    Matrix supports a way to integrate with third-party data sources, but I haven’t read too much into it as it was not in my goals. Perhaps a Synapse (Matrix) plug-in might allow to integrate notes with third-party sources without having to make any changes to the client code. I might investigate this possibility in a later stage.



  • I didn’t know this term! I knew about DAGs which are probably a way to implement CRDTs. I just read the definition on Wikipedia, it says that “[CRDTs feature] an algorithm (itself part of the data type) automatically resolv[ing] any inconsistencies that might occur [in case of conflicts]”, that sounds interesting. I was thinking to try to resolve conflicts automatically whenever possible by adapting Git merge strategies, and when impossible: either just concatenate both versions and let the users fix it manually, or giving users the option to choose line-by-line which version they want.

    With this keyword I might be able to find more literature on the topic. Thank you for suggesting it!


  • Okay, that’s a nice suggestion. I was thinking to try to keep the UI more generic rather than integrate it with operating systems, but an Android widget might not be too hard to do, I might investigate later.

    I do know Node, but I am not skilled with PHP, I haven’t used it for 10 years and I’ve noticed that things have changed a lot since the version I knew. I feel NextCloud is a bit overbloated, but I didn’t think about checking how they handled the communication part, that’s a good idea. It doesn’t overlap much with what I had in mind, but I might still be able to learn something. Thanks!


  • start by scouting around and see if you can adapt FOSS apps

    I see lot of people are recommending me to contribute to existing projects instead of reinventing the wheel. I want this app to be as close as possible as I envision it, I couldn’t find something close enough to what I had in mind (in particular these three things do not seem to get along well: real-time collaboration, simplicity, reliability/stability). But I’ll be honest, I code for fun and I am lazy. Even if there was another project similar enough to this, I don’t think I would want to invest time to learn all the details and then more time to see if it can be adapted to my vision. Starting from scratch is easier, even though it might not be as beneficial to the FOSS community. Still, thank you for suggesting this, that sounds like it would be the smartest thing to do.

    Also, I didn’t know about Murena, thanks for mentioning it!


  • E2EE because I wish for a software that you don’t need to self-host. We here on the Lemmy Selfhosted community are lucky to have the skill to do it, but I want other less tech-savvy users to also be able to use this service without having to trust a third-party.

    It makes backups much more complicated

    You have a point, but if the server acts just as a blind relay to facilitate synchronization, you just need to run this app on a couple of your devices and you have a distributed backup you don’t even need to think about. A copy of all the synchronized documents is stored on your device(s), and it should ideally be exportable at any time, so I would say you don’t need to also have a backup on the server. If you happen to lose all of your devices, you can just add a new one and in a few minutes the server will send you a copy of your data. I would say that makes it unnecessary to keep a plain-text backup on the server, what do you think?

    EDIT: I didn’t want to burden users with a choice of E2EE vs plain-text, but that would be doable I guess. If I end up adopting Matrix, E2EE is optional.


  • Whoa, that’s a long list of ideas… let me see…

    1. That’s the plan, excluding iOS as I do not have a Mac and thus I cannot develop for it
    2. Certainly
    3. Certainly!
    4. That’s not part of the MVP (minimum viable product) I have in mind, but an export function must certainly be added later
    5. Plug-ins are not part of my goal, but I will do my best to keep the source code modular enough to let people adapt it freely
    6. We agree on that, global search is necessary, but I did not think about a “search inside a note” option. That seems to make sense, I’ll see what I can do
    7. Tags are part of my idea, although not the MVP, but folders are not; I will see if I can also add folders without complicating code and UI too much, that doesn’t sound like a bad idea
    8. Not part of my goal, but maybe in a future iteration
    9. Yup, that’s what I had in mind too
    10. As a developer I like Markdown, but it is not on my priority list… perhaps in a future iteration. I was thinking to (maybe) use Markdown behind the curtains, so it might not be too difficult to let users toggle the WYSIWYG
    11. The first UI that I am planning to develop will be for the web browser, then a lazy-man Electron UI for the desktop as well as something for Android, I just wanted to do something simple. I don’t have the time and skills to do deep desktop integration, perhaps in the future, or maybe someone might contribute this feature if this project actually manages to become something interesting
    12. That’s not part of the Simple Notes app I was thinking about, but that would make sense for Simple Calendar, perhaps in the future I might consider linking notes and reminders, but that’s not something I am thinking about yet
    13. I did not think about that, that’s a good idea, I’ll see what I can do
    14. The first version will not let you upload media, but images are planned. I did not think about sound/video/documents, but I guess why not?

    I think notes collaboration might be a anti feature

    That’s the main reason why I decided to build this suite of apps in the first place. I want to be able to work collaboratively on things with my girlfriend, and we must be able to do it in real-time. I realize that this will eat away a big chunk of the total time I will dedicate to this project, but it is also the main reason why I am not satisfied with the options currently available.



  • Oh yeah, I used Joplin in the past. Although the goals are quite different from my idea. Joplin is a great recommendation as an alternative to Google Keep, but it’s not real-time collaborative (or federated, for what it matters).

    create drawings

    Ah, I don’t remember this option. Maybe it wasn’t available when I tried it last time a few years ago. I guess that means Joplin is still being actively developed.

    I would also look into collaborating with the people […] Not sure if that will work, but it’s worth a shot if you’re interested

    Oh! I just noticed that they have quite a few things besides Docs. I mean… I probably should. My goal is for something much smaller, I just want a replacement for Google Keep, and some day in the near future, SplitWise. Joplin sounds like a better candidate than Numerique.

    Thanks for pushing to collaborate, I realize that would actually make more sense than starting a new project from scratch. Not without guilt, I have to admit that I code for fun, and I have more fun working on something that works exactly as I envision it rather than just joining another project. Someday I might learn how to make some real contributions to existing software, but I don’t think this idea of making a simple replacement for Google Keep will be my trampoline to working this way. Still, thank you for trying to push me to do it!


  • Oh yeah, both Joplin and NextCloud are great. I tried them both in the past. NextCloud is a bit bloated in my opinion though, I was hoping to go for something simpler both to install and to use.

    Most of us here on the Lemmy Selfhosted community are skilled enough to keep a computer running somewhere, expose it securely on the internet (or just LAN, if that’s good enough), and install their own services such as Joplin and NextCloud, but my goal would be to make something that you don’t need to self-host. If you can trust any server, you don’t need to host your own. I like the idea of building a network comprised of both self-hosting users, and “normal” users, like here on Lemmy.

    The federation may leave you wanting more and the collaboration might not be “real time” enough for you either, though. If you can build something better by all means go for it.

    I’m not sure I understand what you mean. Do you mean writing a protocol that supports federation is a very difficult thing to do? Actually my first draft didn’t include federation as that’s just too much for my skills. But I am considering adopting Matrix, and Matrix includes federation, so why not? They built real-time messaging with Matrix, so I would assume that should be real-time enough for document editing.






  • Fair enough, but then it’s the same thing as open-sourcing the code but not providing support nor binaries.

    I mean, personally I also prefer it to FUTO’s proprietary license, that’s for sure. But I’m one of the few privileged users who can build from source.

    If this license doesn’t impose any extra restrictions on the code (and as you say, anyone can fork and provide prebuilt binaries), then this would just increase the risk of spreading malware, with no real benefits for the original developers.

    In my opinion, if you want to monetize your software without going proprietary, all you have to do is provide the users a convenient way to get it. There are some paid FOSS apps on Google Play, as well as some paid FOSS games on Steam. You don’t want to distribute binaries? Fine, okay, that’s alright and I respect your choice. You don’t want to provide support to non-paying users? Fine, that’s very reasonable in my opinion. But…

    …do you want to impose extra restrictions on your code? Fine to me, but then you are no longer doing open source, don’t try to pretend you are. And if you are not imposing any restrictions on the code then you are imho just going to hurt small users. We shouldn’t fight small users imho, we should fight the big corporations exploiting FOSS code for their proprietary businesses. But if there are no extra restrictions on the code, then big corporations wouldn’t care.

    That’s my opinion.