Man sagt ja immer so schön das man über den eigenen Tellerrand blicken soll und das mache ich durchaus gerne. Das hat zum Beispiel dazu geführt das ich nach langen Jahren Diaspora verlassen habe und zu Friendica gewechselt bin, welches ich auch jetzt nutze. Aber natürlich war damit nicht Schluss, da man wenn man einmal die Tür zur Welt der auf ActivityPub aufbauenden Plattformen aufgestoßen hat auch mehr darüber erfahren bzw. darin Erfahrungen sammeln will.


(Desktop Screenshots, für eine größere Version bitte das jeweilige Bild anklicken)

Bei den auf ActivityPub basierenden basierenden Plattformen stieß ich abseits von Friendica und Hubzilla nur auf Plattformen welche ähnlich wie Twitter für Kurznachrichten konzipiert sind, etwa Mastodon oder Pleroma. Jedoch hat mich vor kurzem @Michael Vogel im Rahmen eines anderen Themas auf die Plattform Mistpark 2020 aka Misty aufmerksam gemacht. Und ich habe mir auf der bisher einzigen frei zugänglichen Instanz misty.casa einen Account eröffnet um es anzuschauen.


(Mobile Screenshots, für eine größere Version bitte das jeweilige Bild anklicken)

Misty erinnert mich von seiner Oberfläche und Handling stark an Hubzilla und Friendica, was daher kommt das es daher kommt wo auch diese beiden Plattformen ursprünglich kamen, von Zot. Aber es gibt auch Elemente die mich an Facebook erinnern. Das Besondere daran ist wohl das es sich um eine rein ActivityPub basierte Facebook ähnliche Plattform handelt. Sprich man kann längere Artikel verfassen, es gibt strukturiert Kommentardiskussionen und auch Gruppen, auch wenn diese anders als bei Facebook zu handhaben sind. Als kleines Extra für mich als ehemaliger Diaspora User kommt dazu das die Beiträge mit Markdown formatiert werden können.

Natürlich hat auch Mistpark 2020 aka Misty noch viel Entwicklungspotential und auch seine Lücken. So ist die Übersetzung ins deutsche noch nicht komplett. Aber das kann ja noch kommen. Ein Wermutstropfen ist freilich das man wenn man von Diaspora oder Friendica kommt, keinerlei Verbindung zu seinen Diaspora Kontakten herstellen kann, da Diaspora kein AktivityPub kann und bei den Entwicklern auch nicht der geringste Willen ist daran etwas zu ändern.

Tags: #Fediverse #Misty #Mistpark2020 #Erfahrungen #Friendica #Hubzilla #ActivityPub #Mastodon #Pleroma #Zot #Markdown #Ravenbird #2021-07-27

Important decisions about Misskey(Project)
- I(Syuilo) don't accept any issue and pull request to Misskey(Git Repository: https://github.com/misskey-dev/misskey) for an indefinite period of time.
- Due to a reason above,I remove all collaborators from Misskey.Beacuse they still can make a issue and pull request.
-If you have a question and need a help about Misskey,please use Misskey Forum(https://forum.misskey.io/).
- I am only going to develop Misskey. But I may consider of stopping a development of Misskey indefinitely under the certin circumstances.
- If the project could raise a enough fund to continue the development and I can concentrate the project development,I will accept your contribution again.
- I continuousely accept your contribution for mfm.js , misskey.js and so on. These side projects are relatively small and I could continue to handle.

A reason of my decisions as follows
- Lack of my ability of organizing Misskey Projcet
- We could not raise enough fund for project development.
- In relation to above, there is not enough time for me to develop the project, and delay in response to issue and pull request is expected.
...etc

Please note that this post is just a translation of Syuilo original post for Japanese people.

#ActivityPub#misskey#fediverse
RE: https://misskey.io/notes/8of8fhvhi2

Jeder der sich mit den Mechanismen kommerzieller Sozialer Netzwerke wie Facebook, Twitter, Instagram, Youtube & Co beschäftigt, kommt nicht um das Thema Lock-in-Effekt herum. Doch wie ist es mit den nicht kommerziellen dezentralen Alternativen aus? Bei den meisten Projekten bzw. Plattformen des Fediverse ist das dank ActivityPub das sie miteinander verbindet kein Problem.

Anders sieht es jedoch bei Diaspora aus, da es nur sein eigenes Protokoll unterstützt und die Verbindung zum Rest des Fediverse lediglich über Friendica sowie Hubzilla existiert und selbst über diese Brücke alles andere als optimal sind. Will man als Diaspora Benutzer auf eine Plattform mit ActivityPub Unterstützung wechseln, stehen von den verschiedenen Plattformen nur Friendica und Hubzilla zur Verfügung, da nur diese direkte Verbindungen zu Diaspora erlauben und somit nur bei diesen weiterhin der Kontakt zu den bisherigen Diaspora-Kontakten möglich ist. Und genau darin besteht der Lock-in-Effekt bei Diaspora, welcher oftmals verhindert das Benutzer in den ActivityPub Teil des Fediverse wechseln.

Tags: #Gedanken #Diaspora #Lock-in-Effekt #ActivityPub #Soziale-Netzwerke #Ravenbird #2021-07-12

For those of you using the Roadhouse fediverse app, be advised that we will once again be changing the way groups confederate.

TL;DR

If your site provides groups, please don't use Roadhouse at this time. As this project is not widely known or used this shouldn't have a major impact; and other Zap-based projects may be used as a drop-in replacement with no functional difference (the current differences are very subtle and un-noticeable unless you're a protocol developer).

Discussion:

If you provide groups on your Roadhouse server, you may wish to move to a different "Zap based" platform if there are group members using other fediverse software (Mastodon, Pleroma, whatever). Groups do not work under the #ActivityPub protocol if permissions and privacy are involved, so we've provided some workarounds in all our projects. You will see these group posts as embedded shares sent by the group rather than attached "Announce" activities.

This is radically different from groups on other platforms which do not support granular privacy/permissions; and who aren't yet aware that native ActivityPub methods do not work correctly when you add security to the equation.

We will be trialing some extensions to ActivityPub which allow groups and permissions/privacy to actually work correctly over that protocol using its native mechanisms. This effort will be confined to the Roadhouse project at this time to reduce the probability of breaking existing groups.

Until and "if" these extensions (or similar mechanisms) are standardised and picked up by other projects, Roadhouse groups which utilise privacy and default channel permissions will only work correctly on Roadhouse or other Zap-based projects. People using other ActivityPub projects may be unable to post or comment to such groups.

Background:

Under ActivityPub, most projects support groups as "Announce" activities. This is the only existing method in the protocol for sending a message which you didn't initially create to somebody else. The design of ActivityPub is that replies are sent to the 'actor' or author of the original post, who may only accept comments from their own connections and will reject comments sent by group members they aren't connected with personally.

The extension proposed is to add a 'replyTo' field to relayed activities. This indicates that replies are to be sent to the group, and not the original author. This software pattern is critical to corporate messaging and we are merely copying something that has worked well in email for more than half a century. If 'replyTo' exists, all replies to that activity MUST be sent to the 'replyTo' address which in this case will be the group and not the original author.

We also plan to send these as [ "Announce", "Relay" ] instead of "Announce" to indicate that this is a relayed post by an organisation of some kind and not just somebody sharing something they saw in their stream.

In order to more closely align with email, we may or may not also provide a "sender" field which arguably is redundant to "replyTo" in the case of groups but can be applied anywhere that the person sending the message is not the original author and this can then be reflected in the UI.

With these relatively minor additions, we can then use "Announce" as a general purpose relay without any of the associated permission/privacy issues and stop using embedded shares. But (and this is important), this work is meaningless if this is the only project to support these mechanisms.