Skip to main content

Search

Items tagged with: federation


 

The Fediverse strikes back


The Fediverse strikes back – Mastodon und die Hoffnung auf eine Befreiung unserer Sozialen Netzwerke
#fediverse #federation #mastodon #twitter #diaspora #friendica

 

BGP and the Rule of Custom

How the internet self-governs without international law

https://media.ccc.de/v/34c3-9072-bgp_and_the_rule_of_custom

#34c3 #federation #government

 
Here's an interesting report about the decentralised web, published in August by the Digital Currency Initiative at MIT, which includes a pretty fair assessment of the challenges faced by Diaspora over the past 7 years, and the current explosion of interested in Mastodon.

Back to the Future: The decentralized web

There's a link on that page to download the full report as a PDF.

#decentralization #web #federation #federated #diaspora #mastodon

 
Here's an interesting report about the decentralised web, published in August by the Digital Currency Initiative at MIT, which includes a pretty fair assessment of the challenges faced by Diaspora over the past 7 years, and the current explosion of interested in Mastodon.

Back to the Future: The decentralized web

There's a link on that page to download the full report as a PDF.

#decentralization #web #federation #federated #diaspora #mastodon

 
Ah! Shiny new statistics with registered users...

Currently this node is aware of 2080 nodes with 978012 registered users from the following platforms:

  • Friendica (297/1709)
  • diaspora (201/658158)
  • red (17/79)
  • hubzilla (125/1585)
  • GNU Social (173/14909)
  • StatusNet (13/116)
  • Mastodon (1227/301121)
  • Pleroma (27/335)


#federation #fediverse #friendica #statistics

 
Ah! Shiny new statistics with registered users...

Currently this node is aware of 2080 nodes with 978012 registered users from the following platforms:

  • Friendica (297/1709)
  • diaspora (201/658158)
  • red (17/79)
  • hubzilla (125/1585)
  • GNU Social (173/14909)
  • StatusNet (13/116)
  • Mastodon (1227/301121)
  • Pleroma (27/335)


#federation #fediverse #friendica #statistics

 
!Friendica Support
It seems like not all of my toos are federated to #friendica. ❓
Only up to 4 days ago they get federated.(It is sad because I wanted to share all of my images there as well.😕 )
Is that a #bug?
Is there a #federation limit? 🤔


!Friendica Support:
Does friendica not federate older posts from mastodon?

 
#activitypub #federation
" target="_blank">https://t.co/uvhgcPqVrP”[/attachment]

 
Found good use for the new Diaspora URI scheme. For the federation library I need some kind of global identifier when #ActivityPub support is added. A GUID doesn't work since it doesn't define have a location. I was already writing code for <guid>@<domain.tld> format when I saw the Diaspora URI scheme - which fits this usage perfectly 👍 This gives each entity a globally unique URI ID, regardless of protocol.

#devdiary #federation #diaspora

 

Moving away from Twitter


Last Friday, I chose to honor the movement #WomenBoycottTwitter for a full day, not because I'm a woman, but because I've noticed browsing Twitter specifically puts me in a bad mood. This started a bout a year ago with the fateful election of Donald Trump to President of the United States of America and it slowly grew worse over time.

On the same platform, I blocked 3,920 accounts promoting tweets and muted 97 accounts I deemed uninteresting, numbers I would be hard pressed to match on the #Fediverse / #Federation. As long as I was otherwise enjoying the service I didn't mind too much, but now it just looks silly.

However, I have contacts I only have through Twitter, and I'm not ready to completely sever all my ties with them. As a temporary solution, I've enabled #Friendica's Twitter plugin to import my timeline from Twitter in my feed. It's going to increase the volume by about an order of magnitude, so I proceeded to weed out chatty contacts who only made sense on Twitter.

I still have an open account on Twitter, but at least I won't be using their clients, seeing their ads or being shown random offensive tweets on popular retweets. The only regret I have is about Private Messages that aren't compatible with Friendica's. I hope people I know will send me text messages instead but I know it won't happen unless I do it. It's an unfortunate side effect of leaving convenient platforms and I already have first-hand experience of this phenomenon after I was kicked from Facebook.

Thanks for reading!

 

💡 An idea for #federation that I came across in #fediverse

TL;DR: autofollow bot to improve the view of the federation of every instance

Reading GNU Social's manual...
"Hashtags are somewhat limited in GNU social because your server does not have a complete view of the network. Suppose your server has 10 accounts on it. It knows about every post that those 10 people make. If each person follows 10 different people on remote servers, that’s 100 extra people. Now your server knows about the posts from 110 accounts. If you click on a hashtag on your server, it’s only ever possible to see posts from those 110 people."

...makes it clear that all networks have same ~~problems~~ tricks. If a user registers at a small instance (or runs one), they face the issue of an empty stream, or "the ghost town" as some users call it, until they subscribe to many users on different pods. In #Mastodon they came up with autofollow bot, like this one - and here it is at work on one instance, autofollowing Mastodon, GNU Social accounts (and probably other fediverse compatible instances). These bots are doing a good job of making the timeline of smaller instances more interesting. They also help make the fediverse more connected. (They are also used by some who try to collect subscribers in a twitter-ish fashion, following, then unfollowing -- but eh, that's inevitable human nature I guess :)

I haven't come across such bot for #diaspora. So thought it might be useful.

 

 
Finally got myself a sane #logging setup. Previously I've been struggling to make any use of my file based logs, which has led to impossibility in debugging production problems in #Socialhome. Basically what I was doing was setting a few rotating log files and logging to them from all processes. What that means is that the log files just rotate so fast (due to many processes) that you don't really have time to catch problems.

While trying to keep things simple, I was losing a lot of valuable information. More users in the system means more unexpected stuff happening.

So now I've moved to sending all application logs from all processes via #rsyslog to an external service. Right now trying Loggly, which wasn't as easy to set up as they claimed, but is quite nice once done. Good filtering, easy to narrow down on interesting stuff. Great improvement, can squash those random #federation payload processing bugs now :)

Any good recommendations on logging services or good self-hosted logging aggregator apps to set up?

#sysadmin #selfhosted
Homepage

 
Congrats, it is a big step! And welcome to the #Federation!

 
This is a super long post that I am putting into my timeline to annoy @Hypolite Petovan since I am that kind of horrible person. Also - I am making fun of twitter - you know - one of those things that you do inside the #Federation.

 

Progress report on v1.6 | Gargron on Patreon

#Mastodon #ActivityPub #OStatus #Federation

 

federation v0.14.1 released

This release includes an important #Diaspora #protocol related #security fix adding checks so that payloads cannot be sent with objects referencing another identity. Basically this means that a post payload has to have the same author in the object as it has as the sender. The exception is relayables, which are commonly sent by someone else and authored by another person. This the patch release since the latter had to be fixed due to regression.

federation is a #Python library that offers the Diaspora protocol via an opinionated API, aiming to combine multiple protocols under one API in the future.

https://github.com/jaywink/federation/releases/tag/v0.14.1

Changelog:

[0.14.1] - 2017-08-06

Fixed

* Fix regression in handling Diaspora relayables due to security fix in 0.14.0. Payload and entity handle need to be allowed to be different when handling relayables.

[0.14.0] - 2017-08-06

Security

  • Add proper checks to make sure Diaspora protocol payload handle and entity handle are the same. Even though we already verified the signature of the sender, we didn't ensure that the sender isn't trying to fake an entity authored by someone else.
    The Diaspora protocol functions message_to_objects and element_to_objects now require a new parameter, the payload sender handle. These functions should normally not be needed to be used directly.

Changed

  • Breaking change. The high level federation.outbound functions handle_send and handle_create_payload signatures have been changed. This has been done to better represent the objects that are actually sent in and to add an optional parent_user object.
    For both functions the from_user parameter has been renamed to author_user. Optionally a parent_user object can also be passed in. Both the user objects must have private_key and handle attributes. In the case that parent_user is given, that user will be used to sign the payload and for Diaspora relayables an extra parent_author_signature in the payload itself.
#thefederation #federation

 

federation v0.14.1 released

This release includes an important #Diaspora #protocol related #security fix adding checks so that payloads cannot be sent with objects referencing another identity. Basically this means that a post payload has to have the same author in the object as it has as the sender. The exception is relayables, which are commonly sent by someone else and authored by another person. This the patch release since the latter had to be fixed due to regression.

federation is a #Python library that offers the Diaspora protocol via an opinionated API, aiming to combine multiple protocols under one API in the future.

https://github.com/jaywink/federation/releases/tag/v0.14.1

Changelog:

[0.14.1] - 2017-08-06

Fixed

* Fix regression in handling Diaspora relayables due to security fix in 0.14.0. Payload and entity handle need to be allowed to be different when handling relayables.

[0.14.0] - 2017-08-06

Security

  • Add proper checks to make sure Diaspora protocol payload handle and entity handle are the same. Even though we already verified the signature of the sender, we didn't ensure that the sender isn't trying to fake an entity authored by someone else.
    The Diaspora protocol functions message_to_objects and element_to_objects now require a new parameter, the payload sender handle. These functions should normally not be needed to be used directly.

Changed

  • Breaking change. The high level federation.outbound functions handle_send and handle_create_payload signatures have been changed. This has been done to better represent the objects that are actually sent in and to add an optional parent_user object.
    For both functions the from_user parameter has been renamed to author_user. Optionally a parent_user object can also be passed in. Both the user objects must have private_key and handle attributes. In the case that parent_user is given, that user will be used to sign the payload and for Diaspora relayables an extra parent_author_signature in the payload itself.
#thefederation #federation

 

federation version 0.13.0 released

This #Python #federation library release mostly fixes compatibility with the latest #Diaspora federation protocol changes that are rolling out to some nodes.

https://github.com/jaywink/federation/releases/tag/v0.13.0

Changelog

Backwards incompatible changes

* When processing Diaspora payloads, entity used to get a _source_object stored to it. This was an etree.Element created from the source object. Due to serialization issues in applications (for example pushing the object to a task queue or saving to database), _source_object is now a byte string representation for the element done with etree.tostring().

Added

  • New style Diaspora private encrypted JSON payloads are now supported in the receiving side. Outbound private Diaspora payloads are still sent as legacy encrypted payloads. (issue)
    * No additional changes need to be made when calling handle_receive from your task processing. Just pass in the full received XML or JSON payload as a string with recipient user object as before.
  • Add created_at to Diaspora Comment entity XML creator. This is required in renewed Diaspora protocol. (related issue)

Fixed

* Fix getting sender from a combination of legacy Diaspora encrypted payload and new entity names (for example author). This combination probably only existed in this library.
* Correctly extend entity _children. Certain Diaspora payloads caused _children for an entity to be written over by an empty list, causing for example status message photos to not be saved. Correctly do an extend on it. (issue)
* Fix parsing Diaspora profile tag_string into Profile.tag_list if the tag_string is an empty string. This caused the whole Profile object creation to fail. (issue)
* Fix processing Diaspora payload if it is passed to handle_receive as a bytes object. (issue)
* Fix broken Diaspora relayables after latest 0.2.0 protocol changes. Previously relayables worked only because they were reverse engineered from the legacy protocol. Now that XML order is not important and tag names can be different depending on which protocol version, the relayable forwarding broke. To fix, we don't regenerate the entity when forwarding it but store the original received object when generating a parent_author_signature (which is optional in some cases, but we generate it anyway for now). This happens in the previously existing entity.sign_with_parent() method. In the sending part, if the original received object (now with a parent author signature) exists in the entity, we send that to the remote instead of serializing the entity to XML.
* To forward a relayable you must call entity.sign_with_parent() before calling handle_send to send the entity.

Removed

  • Post.photos entity attribute was never used by any code and has been removed. Child entities of type Image are stored in the Post._children as before.
  • Removed deprecated user private key lookup using user.key in Diaspora receive processing. Passed in user objects must now have a private_key attribute.

 

federation version 0.13.0 released

This #Python #federation library release mostly fixes compatibility with the latest #Diaspora federation protocol changes that are rolling out to some nodes.

https://github.com/jaywink/federation/releases/tag/v0.13.0

Changelog

Backwards incompatible changes

* When processing Diaspora payloads, entity used to get a _source_object stored to it. This was an etree.Element created from the source object. Due to serialization issues in applications (for example pushing the object to a task queue or saving to database), _source_object is now a byte string representation for the element done with etree.tostring().

Added

  • New style Diaspora private encrypted JSON payloads are now supported in the receiving side. Outbound private Diaspora payloads are still sent as legacy encrypted payloads. (issue)
    * No additional changes need to be made when calling handle_receive from your task processing. Just pass in the full received XML or JSON payload as a string with recipient user object as before.
  • Add created_at to Diaspora Comment entity XML creator. This is required in renewed Diaspora protocol. (related issue)

Fixed

* Fix getting sender from a combination of legacy Diaspora encrypted payload and new entity names (for example author). This combination probably only existed in this library.
* Correctly extend entity _children. Certain Diaspora payloads caused _children for an entity to be written over by an empty list, causing for example status message photos to not be saved. Correctly do an extend on it. (issue)
* Fix parsing Diaspora profile tag_string into Profile.tag_list if the tag_string is an empty string. This caused the whole Profile object creation to fail. (issue)
* Fix processing Diaspora payload if it is passed to handle_receive as a bytes object. (issue)
* Fix broken Diaspora relayables after latest 0.2.0 protocol changes. Previously relayables worked only because they were reverse engineered from the legacy protocol. Now that XML order is not important and tag names can be different depending on which protocol version, the relayable forwarding broke. To fix, we don't regenerate the entity when forwarding it but store the original received object when generating a parent_author_signature (which is optional in some cases, but we generate it anyway for now). This happens in the previously existing entity.sign_with_parent() method. In the sending part, if the original received object (now with a parent author signature) exists in the entity, we send that to the remote instead of serializing the entity to XML.
* To forward a relayable you must call entity.sign_with_parent() before calling handle_send to send the entity.

Removed

  • Post.photos entity attribute was never used by any code and has been removed. Child entities of type Image are stored in the Post._children as before.
  • Removed deprecated user private key lookup using user.key in Diaspora receive processing. Passed in user objects must now have a private_key attribute.

 
I just found my very first post to the federated network from 2011-05-06. Post number 398 on despora.de. :-) #federation #diaspora #oldhere #cyberarcheology

 
Image/photo
I spent way too much time making this. #federation #clippy

 
Image/photo
I spent way too much time making this. #federation #clippy

 
Hey, folks! I'm visiting #Portland for the first time next week! Does anyone in the Federation live out there?

#diaspora #federation

 
Something I have been thinking would be nice would be pure indexing servers that expose search endpoints for other nodes to implement. A bit like the relays which is a really simple little server that just handles passing on content. But the index server would just listen and store everything it gets sent. There could be many run by volunteers and node admins could choose which one they want to integrate with using a REST API.

An integration for example be allowing users to search by keywords. The index server could have a well tuned search engine (like elasticsearch) which could find relevant posts easily by full text search, not just tags. This would allow finding interesting content and people who post that content, which currently is problem mainly by accident and effort.

Using the relays, the index servers could get filled with content and nodes wouldn't necessarily have to subscribe to every public post available as there would be the option to retrieve some as needed.

And since #Diaspora can these days pull in payloads from old content, you could tell your node to pull in the content from the original source so you can interact with it.

Too many things to do :P

(this oldish #idea extracted from this thread)

 
Something I have been thinking would be nice would be pure indexing servers that expose search endpoints for other nodes to implement. A bit like the relays which is a really simple little server that just handles passing on content. But the index server would just listen and store everything it gets sent. There could be many run by volunteers and node admins could choose which one they want to integrate with using a REST API.

An integration for example be allowing users to search by keywords. The index server could have a well tuned search engine (like elasticsearch) which could find relevant posts easily by full text search, not just tags. This would allow finding interesting content and people who post that content, which currently is problem mainly by accident and effort.

Using the relays, the index servers could get filled with content and nodes wouldn't necessarily have to subscribe to every public post available as there would be the option to retrieve some as needed.

And since #Diaspora can these days pull in payloads from old content, you could tell your node to pull in the content from the original source so you can interact with it.

Too many things to do :P

(this oldish #idea extracted from this thread)

 
Bitching and such :)
No not bitching and it is all related to #federation and #diaspora project. It should be there and the best thing is the community would learn something out of the discussion. Who knows?

 
hallo, ich bin #neuhier.
Ich will herausfinden, wie ich #friendica mit #diaspora, #mastodon etc. verknüpfen kann ( #federation ).
Hat jemand Tipps dazu?

 
Image/photo

Dear Federation, we are pleased to announce the immedeate availability of Friendica "Asparagus" 3.5.2.

The main focus of the last few months' work was spent on internal code restructuring and performance enhancements. For a full list of changes, please refer to the CHANGELOG file. The highlights are:

  • Enhanced compatibility with MySQL 5.7+.
  • New support for 4 bytes unicode characters (mostly used for emojis). MySQL version 5.5.3 is now a hard minimum requirement.
  • Enhanced federation with Mastodon and preparation for upcoming changes in the Diaspora protocol.
  • The switch to the worker process introduced in the 3.5.1 version as the background process mechanism as it has a better performance. If you are using poorman's cron, external cron or proc runner for the background process, you have to adopt to the frontend worker (see docs) as it makes these addons obsolete.
  • The most visible change is the long time project lead by Rabuzarus, the "frio" theme, which finally removed the "experimental" flag. It still is not 100 percent complete, but it is ready for daily usage.


Addtionally we fixed numerous bugs that the community had found and we polished some quirks.

Blog post: http://friendi.ca/2017/06/06/friendica-3-5-2-released/

#friendica #release #federation @Libranet Support

 

Friendica 3.5.2 released


Image/photo

Dear Federation, we are pleased to announce the immedeate availability of Friendica "Asparagus" 3.5.2.

The main focus of the last few months' work was spent on internal code restructuring and performance enhancements. For a full list of changes, please refer to the CHANGELOG file. The highlights are:

  • Enhanced compatibility with MySQL 5.7+.
  • New support for 4 bytes unicode characters (mostly used for emojis). MySQL version 5.5.3 is now a hard minimum requirement.
  • Enhanced federation with Mastodon and preparation for upcoming changes in the Diaspora protocol.
  • The switch to the worker process introduced in the 3.5.1 version as the background process mechanism as it has a better performance. If you are using poorman's cron, external cron or proc runner for the background process, you have to adopt to the frontend worker (see docs) as it makes these addons obsolete.
  • The most visible change is the long time project lead by Rabuzarus, the "frio" theme, which finally removed the "experimental" flag. It still is not 100 percent complete, but it is ready for daily usage.


Addtionally we fixed numerous bugs that the community had found and we polished some quirks.

Blog post: http://friendi.ca/2017/06/06/friendica-3-5-2-released/

#friendica #release #federation @Libranet Support

 
Yay, not far from getting follows working in #Socialhome. Just UI buttons missing, #federation layer works 😅

Image/photo

 

The Great Diaspora Treasure Hunt

Sometimes the stream is just dull and reshared. I have read some places were people discuss the endless reshares, and discusses how much quality contant this place needs to get going. But the truth is that resharing is like ants in the forest. They can be quite a nuisance, but they are a valuable part of the ecosystem as they help the federation of this place.

Only... why repost the same thing you just saw reposted. The clever ant goes on a treasure hunt in old posts. The good thing by doing this is the post might fell new even if it's an oldie'n'goodie, the chance of dublicates in the stream is minmal, and, most important, it will help new pods be part of the history of Diaspora and Friendica. Digging up a really interesting, fun, thoughtprovoking or obscene post from the past makes you a Diaspora archelologist, a pillar of federation society, a provider of quality content to the hungry masses - and it's (almost) just as easy as a normal reshare.

So if you are bored with the stream go on find some old posts, the older the better, the less reshares the better, the better the better.

I will at least try to do this more often ...



#Diaspora #friendica #reshares #federation #treasure #hunt

 
I really think it would be cool to able to "browse" the public streams of a specific pod (maybe podmins could enable/disable publishing their public feed this way in the yml)
Right now, I have added the few recommended accounts to follow (from the install wiki) and yet my feed is ... well ... there is the sound of a lone cricket chirping, so maybe I'm just impatient.

#diaspora #podmin #privacy #federation

 

federation v0.12.0 released

#Python #federation now includes more support for the upcoming #diaspora protocol breaking changes and also includes support for the new Contact entity type. Additionally, legacy sharing/following Request entity has fixes.

Repository: https://github.com/jaywink/federation

Changelog:

Backwards incompatible changes

* Removed exception class NoHeaderInMessageError. New style Diaspora protocol does not have a custom header in the Salmon magic envelope and thus there is no need to raise this anywhere.

Added

  • New style Diaspora public payloads are now supported (see here). Old style payloads are still supported. Payloads are also still sent out old style.
  • Add new Follow base entity and support for the new Diaspora "contact" payload. The simple Follow maps to Diaspora contact entity with following/sharing both true or false. Sharing as a separate concept is not currently supported.
  • Added _receiving_guid to all entities. This is filled with user.guid if user is passed to federation.inbound.handle_receive and it has a guid. Normally in for example Diaspora, this will always be done in private payloads.

Fixed

* Legacy Diaspora retraction of sharing/following is now supported correctly. The end result is a DiasporaRetraction for entity type Profile. Since the payload doesn't contain the receiving user for a sharing/following retraction in legacy Diaspora protocol, we store the guid of the user in the entity as _receiving_guid, assuming it was passed in for processing.

 

federation v0.12.0 released

#Python #federation now includes more support for the upcoming #diaspora protocol breaking changes and also includes support for the new Contact entity type. Additionally, legacy sharing/following Request entity has fixes.

Repository: https://github.com/jaywink/federation

Changelog:

Backwards incompatible changes

* Removed exception class NoHeaderInMessageError. New style Diaspora protocol does not have a custom header in the Salmon magic envelope and thus there is no need to raise this anywhere.

Added

  • New style Diaspora public payloads are now supported (see here). Old style payloads are still supported. Payloads are also still sent out old style.
  • Add new Follow base entity and support for the new Diaspora "contact" payload. The simple Follow maps to Diaspora contact entity with following/sharing both true or false. Sharing as a separate concept is not currently supported.
  • Added _receiving_guid to all entities. This is filled with user.guid if user is passed to federation.inbound.handle_receive and it has a guid. Normally in for example Diaspora, this will always be done in private payloads.

Fixed

* Legacy Diaspora retraction of sharing/following is now supported correctly. The end result is a DiasporaRetraction for entity type Profile. Since the payload doesn't contain the receiving user for a sharing/following retraction in legacy Diaspora protocol, we store the guid of the user in the entity as _receiving_guid, assuming it was passed in for processing.

 

federation v0.12.0 released

#Python #federation now includes more support for the upcoming #diaspora protocol breaking changes and also includes support for the new Contact entity type. Additionally, legacy sharing/following Request entity has fixes.

Repository: https://github.com/jaywink/federation

Changelog:

Backwards incompatible changes

* Removed exception class NoHeaderInMessageError. New style Diaspora protocol does not have a custom header in the Salmon magic envelope and thus there is no need to raise this anywhere.

Added

  • New style Diaspora public payloads are now supported (see here). Old style payloads are still supported. Payloads are also still sent out old style.
  • Add new Follow base entity and support for the new Diaspora "contact" payload. The simple Follow maps to Diaspora contact entity with following/sharing both true or false. Sharing as a separate concept is not currently supported.
  • Added _receiving_guid to all entities. This is filled with user.guid if user is passed to federation.inbound.handle_receive and it has a guid. Normally in for example Diaspora, this will always be done in private payloads.

Fixed

* Legacy Diaspora retraction of sharing/following is now supported correctly. The end result is a DiasporaRetraction for entity type Profile. Since the payload doesn't contain the receiving user for a sharing/following retraction in legacy Diaspora protocol, we store the guid of the user in the entity as _receiving_guid, assuming it was passed in for processing.

 

The Great Diaspora Treasure Hunt

Sometimes the stream is just dull and reshared. I have read some places were people discuss the endless reshares, and discusses how much quality contant this place needs to get going. But the truth is that resharing is like ants in the forest. They can be quite a nuisance, but they are a valuable part of the ecosystem as they help the federation of this place.

Only... why repost the same thing you just saw reposted. The clever ant goes on a treasure hunt in old posts. The good thing by doing this is the post might fell new even if it's an oldie'n'goodie, the chance of dublicates in the stream is minmal, and, most important, it will help new pods be part of the history of Diaspora and Friendica. Digging up a really interesting, fun, thoughtprovoking or obscene post from the past makes you a Diaspora archelologist, a pillar of federation society, a provider of quality content to the hungry masses - and it's (almost) just as easy as a normal reshare.

So if you are bored with the stream go on find some old posts, the older the better, the less reshares the better, the better the better.

I will at least try to do this more often ...



#Diaspora #friendica #reshares #federation #treasure #hunt

 
Image/photo

About Reshares

I wrote this on Steemit because I would like if people could toggle reshares on/off when they look at a profile.

It might also be an idea for Diaspora. Sometimes you would like to see what a person actually posts, and nor his/her reshares.

https://steemit.com/resteem/@katharsisdrill/about-the-importance-of-reshares-and-the-problem-with-reshares

#reshare #Facebook #Diaspora #Mastodon #Friendica #Steemit #federation #social-media #SM #people #interaction

 
Image/photo

About Reshares

I wrote this on Steemit because I would like if people could toggle reshares on/off when they look at a profile.

It might also be an idea for Diaspora. Sometimes you would like to see what a person actually posts, and nor his/her reshares.

https://steemit.com/resteem/@katharsisdrill/about-the-importance-of-reshares-and-the-problem-with-reshares

#reshare #Facebook #Diaspora #Mastodon #Friendica #Steemit #federation #social-media #SM #people #interaction

 
git checkout -b activitypub

Time to start taking #Python #federation to multi-protocol stage, as it was planned to be from the start ;) Might take a while but got to start some day!

#activitypub

 
#Federation #Decentralization #w3c

 
@nolan Would one see the replies if the replies are from someone else that they follow along with following you?

Seems like it'd be great to see replies from /everyone/ in each conversation one participates in in order to make it easier to find other people to connect with.

#LetsMakeFriends #InstanceSharing #Threads #SeeMe #Federation #Quirks

 

GNU Social isn't for me


To replace Facebook in my life, I self-hosted an instance of Diaspora then Friendica (from where I'm writing right now), and I thought I could self-host a GNU Social instance to better communicate with Mastodon accounts.

However, I quickly realized that I wouldn't be able to use it for a simple reason: my timeline was filled with replies to conversations I wasn't a part of. The ratio signal/noise is then extremely low. I've been told it's a feature of the OStatus protocol, which means it won't get fixed anytime soon.

At Friendica we support OStatus but we mitigate the clutter by threading conversations and trying to ignore replies that don't concern us. It doesn't work completely reliably, but for me it already is heaps better than the constant chatter I couldn't make sense of in GNU Social.

#federation #friendica #gnusocial #mastodon

 
To celebrate the new coming up #NodeInfo version, which improves slightly but still falls short for being a flexible way of describing server metadata, I updated my alternative version draft a bit. The spec now gives recommendation on how to expose metadata from #ActivityPub implementers, which the original NodeInfo is not suitable for (due to dependence on /.well-known and multiple versioning).

https://github.com/jaywink/nodeinfo2

Comments welcome :) WIll implement in the-federation.info soon.

#decentralization #federation

 
#activitypub #federation #tutorial
" target="_blank">https://t.co/xQ4Xy7OsB1”[/attachment][/share]