Ben Matthews

  • New here on lemmy, will add more info later …
  • Also on mdon: @benjhm@scicomm.xyz
  • Try my interactive climate / futures model: SWIM
  • 0 Posts
  • 26 Comments
Joined 2 years ago
cake
Cake day: September 15th, 2023

help-circle
  • Well problem with any Lemmy community as such a forum, is that current usage (not necessarily intrinsic to the software) is so ephemeral. So it’s good for discussing breaking news, but not to gradually accumulate discussion of solutions to complex problems, over years. I wish this were not the case, but doubt anybody will even notice this comment, as no longer ‘hot’, and folded away … Rather, a few weeks later the same topic will be reopened under a different post, and we start over again.


  • I agree with most of what you say. I’m a long-time fan of calculating more complex things client side, as you can see from my climate model (currently all calcs within web browser, evolved from java applet to scalajs).
    Also, in regarding social media, keeping the data client side could make the network more resilient in autocratic countries (many), and thelp this become truly a global alternative.
    On the other hand, some ‘trunk’ server interactions could also doing more not less, bundling many ‘activity’ messages together for efficiency - especially to reduce the duplication of meta-info headers in clunky json, and work of authentification-checking (which I suppose has to happen to propagate every upvote in Lemmy?).


  • Thanks, that makes sense if I think about it, but maybe users shouldn’t have to - i.e. the Mdon part-conversation way still seems confusing to me (despite being a climate modeler and scala dev), although haven’t used Mdon much since I found Lemmy. And I still feel that both ways seem intrinsically inefficient - for different reasons - if we intend to scale up the global numbers (relating OP).


  • That makes sense, to store only popular stuff, or temporarily - especially for ‘heavier’ images (although as we see with lemm.ee, that leads to issues when an instance dies). Yet I also wonder about the scalability of just the minimum meta-info, whose size does depend on the protocol design.
    For example with Lemmy every upvote click propagates across the network (if i understand correctly, mastodon doesn’t propagate ‘likes’ so consistently, presumably for efficiency, but this can make it seem ‘empty’). Maybe such meta-info could be batched, or gathered by a smaller set of ‘node’ instances, from which others pick up periodically - some tree to disperse information rather than directly each instance to each other instance ?
    As the fediverse grows, gathering past meta-info might also become a barrier to new entrant instances ?




  • Two thoughts:

    • I’m subscribed to 160 communities, most very small, but see interesting stuff due to the Scaled option - also deliberately avoid the big news communities. Evidently, it takes time to join 160 small cs, so to get started it could be handy to have an all/local except list, and remove the biggest news /memes unless people tick a box saying they like such. Or make an algorithm that prioritises stuff related to what I upvote (which is how other social sites seem to get people started - e.g. i just tried rednote and it quickly learned i like mountains and trains) - but i guess that’s hard to implement as each instance would need to work out ‘related to’.
    • 2nd point - there are other user-interfaces - I’m using Alexandrite which has a better layout than lemmy default, but how to make this easier (instructions suggest docker, how many casual users will do that …)?

  • I might try Friendica, although coming from lemmy I’d be more inclined towards Mbin, to combine topic-focus and people-focus.
    However as a developer I first check the code repos and see that both are based on php, which seems rather old, and i doubt this would scale efficiently if the network really took off. Recall that twitter was once based on ruby (like mastodon is) and shifted to scala for such reasons. So I feel, these are exploring well the potential user-experience, but the code may need a fresh structure (if somebody knows this tech issue better, please say). It’s good to discuss these things, to help consolidate potential efforts.









  • Ben Matthews@sopuli.xyztoOpen Source@lemmy.mlThe Death of Decentralized Email
    link
    fedilink
    Français
    arrow-up
    50
    arrow-down
    1
    ·
    edit-2
    1 year ago

    I don’t buy this. I’m still using SMTP on my own domain and it’s working fine, a bit of spam but not unmanageable, real messages get read. Main challenge is digesting so many potentially-interesting list messages, indicating email’s continued dominance for professional topics. Seems this author has another agenda.
    Having said that, it’s a pity the world never agreed a protocol for micro-payment for emails (and for many other services), which would resolve the spam problem, and not be a burden for honest users.





  • Well, for example if I could reply to a mastodon post from my lemmy account - the poster would see that there (not here - but could show up on my profile page), and might follow it, so it could gain followers. To write such a reply, I’d need to somehow view the original post while logged into lemmy. My comments here do federate to mastodon, and if somebody searched for related words (at least from the instance from which I followed my #lemmy account) they should find this. Your “virtual community” seems like a mastodon list (I have a dozen such topic lists, that system could be better, but is improving), indeed it would be helpful to consider that alongside a lemmy community for similar topic.