Some random ideas about how likes should work in a social network, e.g. #Movim #Salutatoi #Libervia in the long run.

I'm referring to postings only, not chat.

Social networks are all getting high by the alternation of Adrenaline and Dopamine, intensified by the occasional dose rate of Caffeine, when geting #likes.

1. On Movim, I can get information about recent likes in the notifications, but I would like to have an overview about all likes I ever got.
2. Also, I'm missing an overview about all postings, that I liked at some point.
3. In social networks one can find like-minded people. How about notifying me, when posting I liked or commented on, get more likes or comments by others? #Diaspora does this.
4. Movim only allows for a like, but not for any other reaction. Message Reactions OTOH, allow for multiple, different #reactions, which I find more interesting.
5. If a network becomes larger, fraud and abuse will be quick to follow. I'll post "vi is great", wait for some likes, and the correct the post to "Emacs is great". My likers will not even get a notification, nor is there a change history. Diaspora "solves" this by not allowing changes of posts, which is horrible - I can't even fix my typos. #Mastodon seems to replace the orginal post with a complete new one on change - losing answers and likes (favourites). Therefore:
   1. Likers must be notified, if a posting they liked has been altered, so that they can decide to remove their reaction.
   2. A change history should be visible.
6. When talking about fraud and abuse: At some point, it should be possible to digitally sign postings, e.g. using #OX, so that everybody can verify the authenticity of a posting. This is esp. important in a federated network, where fake sites might appear. Likewise, reactions should be optionally signed, too.

Berlin Online XMPP Sprint 2020

The planned XMPP sprint in Berlin from Thursday, 2020-03-26 to Sunday, 2020-03-29, will take place despite the current crisis. But instead of an in-person meeting, it will be an online event!

We will mainly use the XMPP group chat xmpp:xmpp-sprint@chat.cluxia.eu?join for all coordination, and multiple Jitsi instances for audio/video conferencing, maybe also mumble for voice chat.

Please find all details in the wiki and consider participation! This time, there are neither travel nor hotel costs! https://wiki.xmpp.org/web/Sprints/2020_March_Berlin

See you at the Berlin Online XMPP Sprint! Berlin is whereever you are!

#xmpp #sprint #event #community #hacking #freesoftware #uwpx #beagleim #siskinim #xmppjs #omemo #kaidan #smack #dino #omemo #prosody #xmpprs #salutatoi #debian #jitsi

XMPP Hacking Night

Instead of boring talk, this time, we will hack on our favourtite projects, hopefully XMPP related. Some ideas: See the tags! Non-hackers welcome, if you have fun watching programming monkeys at their outdated notebook computers. Anyway, there will be a lot of chit chat.

When? Wednesday, 2020-01-08 18:00 CET (always 2ⁿᵈ Wednesday of every month)

Where?xHain hack+makespace, Grünberger Str. 16, 10243 Berlin (as always)

See you then!

Or join our non-physical room (xmpp:berlin-meetup@conference.conversations.im?join)!

#xmpp #community #xhain #hacking #freesoftware #berlin #meetup #kaidan #dino #sms4you #salutatoi #ejabberd #chat

Dennis Schubert: ActivityPub - Final thoughts, one year later.

Maybe Diaspora could be re-implemented using XMPP? :-)

I would like to hold XMPP up as an example, here. If you do not know XMPP, it is short for Extensible Messaging and Presence Protocol, a protocol for building distributed instant messaging applications. While extensibility was so important they even made it part of the protocol’s name, they did not want to end up with a runaway specification that depends on having implementers talk to each other to be working reliably.

Instead, they wrote a very strict base set of the absolute minimums required to build on XMPP, and pushed that through the IETF’s standards track, ending up with what is now RFC 6120. Acknowledging that they can never address all needs in such a strict specification document, they opened themselves for more flexibility:

This document specifies how clients connect to servers and specifies the basic semantics of XML stanzas. However, this document does not define the “payloads” of the XML stanzas that might be exchanged once a connection is successfully established; instead, those payloads are defined by various XMPP extensions. For example, [XMPP-IM] defines extensions for basic instant messaging and presence functionality. In addition, various specifications produced in the XSF’s XEP series [XEP-0001] define extensions for a wide range of applications.

They introduced XEPs, XMPP Extensions Protocols. The very first XEP ever published, XEP-0001, describes the process of getting a new XEP published to the world, and that process of that is not very hard to understand or tricky to follow. Everyone is invited to submit a proposal, you do not have to be a member of any organization, and in fact, you do not even need to maintain your own implementation. As long as your proposal follows the rules and matches the required format, it will be taken into consideration. After a proposal has been made, there is a specific chain of events, but it boils down to an open discussion on those proposals, and if there are no more doubts or things to improve, and if people agree that the proposal would be a useful thing to standardize, the proposal will eventually end up as an actual XEP.

At the time of writing, there are 151 active, draft, experimental, final, or proposed XEPs, and all of them can be found on the XMPP Standards Foundation’s website. Everyone interested in reading up on those topics, for example because they want to implement a client or a server, can find those documents there, and there is also a central infrastructure for asking questions and proposing improvements, which is open to everyone. This way, the XSF has ensured XMPP can be extended to all imaginable use cases, without ending up with watered-down or vague specifications.

If, for example, I wanted to implement an XMPP server or a client4, I could read the relevant RFCs as well as the XEPs that are relevant to my project. Some documents, like XEP-0387 for example, would even help me out deciding which XEPs are essential, by listing the things that are important when building a web client, or an advanced desktop client, or a mobile application, … There would be no need for me to talk to other XMPP server or client implementers for my implementation to work, and I could be very comfortable about the interoperability of my systems if I built them in accordance to the specifications. That is what specifications are meant to be.

#activitypub #diaspora #standards #xmpp #movim #salutatoi #xep