@jorgeluis haven't so far, what would you need it for? LDAP is a much older protocol than OpenID Connect or OAuth, but I guess that means there's things than only support that...
Bientôt le Mondial de foot … chic chic chic 🙄
#humour #football #qatar #esclavagisme
Si vous êtes à la recherche d'un poste de développeu·r·se, il y a des opportunités chez /e/ :
https://doc.e.foundation/jobs
#emploi
C'est bizarre que BeinSport n'a pas acheté les droits …
#humour
It may be better to put this in a shared pad to work among various folxs, but let's start here the talk and see WDYT... :)
** Generalisms...
Communication today has so many channels/media that fragmentation is a serious issue for many people and organizations. Today is common for groups to talk via more than one of many methods like Slack (or similar channel based chats or CBCs like RocketChat, Zulip, Mattermost, etc.), Whatsapp (yuk!), Telegram, Signal or Matrix, Email, maybe Google Talk, Discord (or similar services like Guilded) and more. Classics are still there for those that appreciate them, like XMPP. And may the Earth spirits prevent you from having to use Microsoft Teams. There are even more and newer ones, and very interesting ones as Scuttlebutt...
Each channel has it's own characteristics that results in some weaknesses and some strengths. 2 of the most used are:
+ Email :: An ordered conversation. (perceived as) solid, slow, known, trustable, deep, completely interoperable, with an order based on folders. Keeps threading. Young people don't use it for communications (only as account for other services).
+ Instant Messaging (IM) ordered as channel based chats (CBC) :: a river that flows endlessly. (perceived as) easy, fast, because of that quite superficial, with an order based on people/group. While possible, not much threading used really (doesn't keep context well). Young and old people uses it a lot because it's easy and fast.
The proposed hypothesis here is that an activity server with some pluses as Bonfire is developing may be a bridge between these 2 universes; in other words, a sweet spot between email and IM/CBCs apps.
What is good about e-mail as a medium? In my opinion, the capacity to be precise in which you include or not in the conversations, and the possibility of having deep conversations (may be derived from an open UI and the non-synchronous expectation?).
What is good about IMs as a medium? They are easy and fast.
Where does Bonfire fits in here? I think that in a sweet spot in the middle with the best of each media. :)
Bonfire:
- is fast :: with a good mobile app or in a browser it allows for fast and simple replies is someone needs them. And if you put notification for everything, it's almost like any IM.
- allows a lot of precision in terms of destinations :: individual people, groups (circles), the whose instance, the whole Fediverse, only self defined interested people (with hashtags or themes) and permissions (what are now boundaries). These can be -or not- listed just as channel based chats do, but can include more than one destination (something channel based chats can't do, you either write in "Dev" or in "UX" or in "General", or copy the message and follows each copy thread).
- keeps context :: this doesn't needs anything from the user, just hitting "reply" means the server keeps the thread and that those threads can be named and addressed.
- allows serious replies :: it's editor is generous and allows quotes.
- interoperates :: with any other ActivityPub talking services. Like email, you are not bounded by your domain and the same tool can be used with close or far away, know or new ones.
** Bonfire for an organization
Additionally, Bonfire has some benefits for any organization:
- it's safe :: it keeps the information (and can be backed up) in the server, so it doesn't depends on the backup of any device or person.
- it's sovereign :: with a minimum of technological knowledge any organization can have it's owns safe space for communication.
** What is done and what it may need to serve this communication needs?
TBD
Some things can make this possibility a reality faster.
- A great mobile interaction :: for many people, this is a must. Notifications should be precise and customizable. Writing should be generous. Audio messages must be allowed?
- Others? :: ...
🤵♂️ ¡ Allez les hommes, on se motive et on prend en charge la contraception du couple !
📻 Un podcast très intéressant sur le sujet : La contraception masculine : la bourse ou la vie ? Sur France Culture :
https://www.radiofrance.fr/franceculture/podcasts/la-science-cqfd/la-contraception-masculine-la-bourse-ou-la-vie-7013846
Et je vous invite à prolonger la discussion, sur le thème de la contraception en général (masculine et féminine) dans le salon Matrix dédié : #contraception:matrix.rptc.bid
Erving Goffman's "Asylum" is an excellent reading on how not to implement a social media : the capitalistic ones are designed to turn into total institutions for their socially isolated users. I won't mince words to please do-gooders, cutting millions of people's time schedules to the bone of meals and 5 hours of sleep per night, lifting social activities, studies, work, and family life, is a crime against humanity.
Sorry I'm tired. I didn't sleep well last night, I woke up 8 times.
I'm about 60% sure that Twitter is designed around Goffman's "Asylum" to optimize its communities towards aggregating isolated teenagers and turning into total institutions. This is, anyway, how these communities behave, and it drives both user retention and their AFK isolation. Isolating the victim is a classic abuse strategy and a lot of power dispositives accumulate to actually make Twitter users toxic, joke about ruining Christmas dinners with political discussions, etc. I've read Måneskin fans tweet about Twitter bringing up the worst in them.
So basically, if you have a specific app/platform you'd like to try this with, it should be possible (depending on what the other software supports of course), but some testing and tweaking of the implementation will need to be done.
Those are great news!
In our particular case, Moodle will be used but it can go both ways. Moodle can id Bonfire or viceversa. It looks like Moodle can take Open ID info (see moodle.org/plugins/auth_oidc).
But also Bonfire can take it from Moodle.
Anyway, I'm happy that it's something going on and I would be happy to help with tests (or other things that don't require programming). 😅
Erving Goffman's "Asylum" is an excellent reading on how not to implement a social media : the capitalistic ones are designed to turn into total institutions for their socially isolated users. I won't mince words to please do-gooders, cutting millions of people's time schedules to the bone of meals and 5 hours of sleep per night, lifting social activities, studies, work, and family life, is a crime against humanity.
Great questions! This is indeed something I am very interested in and have started to prototype: github.com/bonfire-networks/...
An extension to enable:
- authenticating on Bonfire using an external identity using OpenID Connect
- using your Bonfire identity to authenticate in other apps with OpenID Connect 1.0 or OAuth 2.0
So basically, if you have a specific app/platform you'd like to try this with, it should be possible (depending on what the other software supports of course), but some testing and tweaking of the implementation will need to be done.
Authenticating Bonfire users from other sources
If it's not the time to ask this I'm sorry and please simply dismiss this post.
Imagine that you already have a community working on a CMS or LMS (like Moodle, Wordpress, Discourse, Drupal, etc.) with a bunch of users and a way to manage them (create, give roles/permissions, delete, etc.).
Is it, now or planned in a near future, a way to somehow connect that with a Bonfire instance so we don't need to have double users, one in each platform? Or -in the other way- can Bonfire provide this authentication? One platform to rule them all, one platform to find them, one platform to bring them all and in the Fediverse light bask them? 🤣
In brief: can Bonfire accept/provide identification by/to other sources?
Thanks a lot, and I hope this discussion opens some possibilities. :)
Great questions! This is indeed something I am very interested in and have started to prototype: github.com/bonfire-networks/...
An extension to enable:
- authenticating on Bonfire using an external identity using OpenID Connect
- using your Bonfire identity to authenticate in other apps with OpenID Connect 1.0 or OAuth 2.0
Authenticating Bonfire users from other sources
If it's not the time to ask this I'm sorry and please simply dismiss this post.
Imagine that you already have a community working on a CMS or LMS (like Moodle, Wordpress, Discourse, Drupal, etc.) with a bunch of users and a way to manage them (create, give roles/permissions, delete, etc.).
Is it, now or planned in a near future, a way to somehow connect that with a Bonfire instance so we don't need to have double users, one in each platform? Or -in the other way- can Bonfire provide this authentication? One platform to rule them all, one platform to find them, one platform to bring them all and in the Fediverse light bask them? 🤣
In brief: can Bonfire accept/provide identification by/to other sources?
Thanks a lot, and I hope this discussion opens some possibilities. :)
or alternatively we can leave the feed as it is, but showing more context when the user click on the reply icon.
Rather than just showing the replied to post above the composer box, we can show a more contexted set of information related to the thread (We can merge the read discussion and the reply icon together, so that when you click on the reply icon it shows the thread and load the position where you want to reply to ?)
Ohh this is a good idea anyway, even if we add more info in the feed!
Oomph I can imagine how difficult that is in a federated setting.! Maybe a balance can be found that just gives a rough sense of the "context size" of a post instead of being very exact about the whole thread metadata?
or alternatively we can leave the feed as it is, but showing more context when the user click on the reply icon.
Rather than just showing the replied to post above the composer box, we can show a more contexted set of information related to the thread (We can merge the read discussion and the reply icon together, so that when you click on the reply icon it shows the thread and load the position where you want to reply to ?)
From a technical point of view, adding such info in feed views without impacting loading times to a point where it's not usable will probably mean we need to introduce caching (which we luckily haven't needed until now, as cache invalidation is famously said to be one of the "2 hard problems in computer science")... but it does indeed seem worthwhile!
Oomph I can imagine how difficult that is in a federated setting.! Maybe a balance can be found that just gives a rough sense of the "context size" of a post instead of being very exact about the whole thread metadata?
I have a suggestion for Bonfire:
@BonfireBuilders #bonfire_feedback
Bonfire does a lot of great things with single posts:
- show them in a "timeline" view as they occur
- according to who I follow
- according to what topics I follow
- according to the instance I'm on
- personal messages
- show them in a threaded view highlighting semantic connections
- according to filters, such as searches for tags, or taking into account blocked users
It is everything that you'd want, but also a bit much. In particular, after seeing the threaded view once, I'm always having the impression that I am missing something when looking at a post. Bonfire allows for quite a rich context for every post, but most views present single posts. They might be parts of threads that I haven't visited before and therefore might misinterpret. I have to click on every post to see it in thread view to understand if I'm indeed missing something.
It would be great if each post would feature some information about its context. For instance, it could show a mini-map of the thread, or display metadata like "part of a conversation started 2022-09-19, 4 participaring users, 34 messages (3 unread)"
If threads were more of a basic unit users would interact with (rather than single posts), it could also be possible to mute a thread. For instance when all your friends start to talk about some sporting event that you're not interested in or whatever.
Things like that could encourage better discussions, as in slower, less repetitive, more interaction with other thread participants.
From a technical point of view, adding such info in feed views without impacting loading times to a point where it's not usable will probably mean we need to introduce caching (which we luckily haven't needed until now, as cache invalidation is famously said to be one of the "2 hard problems in computer science")... but it does indeed seem worthwhile!
this makes a lot of sense, especially since our thread UX is not the flat standard one, when a user replies from the timeline, they don't know in which layer of the tree they're replying to.
There is always a balance to find between overwhelming the feed showing too much info per single post and not giving enough context to the user (as it is now in bonfire and most of the social networks i'm aware of)
My sense is that commercial social networks have a high interest in providing minimal context. Minimal context increases engagement because users cannot figure out what has already been said in a discussion. Discussions most of the time look as if everything is still very "open" even if hundreds of messages already exist. The most "successful" posts on commercial social media work best without requiring any context. Such posts can be easily algorithmically processed, and presented to users at any time in any other context. Even the slightest improvement in that era would make bonfire stand out. The current nested thread view is already a great contribution.
