Skip to main content

Search

Items tagged with: federation


 
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

diaspora:// URI scheme - diaspora* federation protocol

diaspora:// URI scheme - diaspora* federation protocol

 

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.

gled-rs/mastodon-autofollow

mastodon-autofollow - Autofollow bot for mastodon

 
@vectorpoem However, I'm still going to be available on the #Fediverse and the #Federation, via @MastodonProject for example.

MrPetovan's Friendica (profile)

MrPetovan's Friendica (profile)

 
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 https://www.loggly.com/

 
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

Progress report on v1.6 | Gargron on Patreon

Official Post from Gargron: Hey folks, it's been somewhat close to a month since the last release. I am hoping to push it out in the coming weeks, though as some matters are outside my control, I cannot predict the exact time. (Though as always, it will begin with release candidates! To collect translation updates, find bugs,

 

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

jaywink/federation

Python library for abstracting social federation protocols

 

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

jaywink/federation

Python library for abstracting social federation protocols

 

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.

jaywink/federation

Python library for abstracting social federation protocols

 

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.

jaywink/federation

Python library for abstracting social federation protocols

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

Ein erstes Posting mit schönem Foto von der Moritzburg Halle.

Ein erstes Posting mit schönem Foto von der Moritzburg Halle.
#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)

Federation

Federation
Today, I have fiddled around a bit with the #gnusocial network, yesterday I checked out #Hubzilla. I must say that, for now, I find all of them pretty much equally good, but I found all of them to be weak in one very important aspect. I would like to know your thoughts about this.
IMHO, neither gnusocial, nor Hubzilla, nor diaspora* are handling #federation well. I would, from whatever I read about the systems, expect any pod, hub, or instance to be able to synchronise with all the others. There should be a protocol to gather all posts from all pods, hubs, or servers, not only the ones that someone from your own pod/hub/server has already added.
I opened what is here called the public activity on two different #quitter (a gnusocial installation) servers, only to be shown two entirely different timelines. Not even ten percent were shared content.
Maybe I have the wrong idea of what all this should be or has been made for, but as far as I can tell, social media are in part...

 
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)

Federation

Federation
Today, I have fiddled around a bit with the #gnusocial network, yesterday I checked out #Hubzilla. I must say that, for now, I find all of them pretty much equally good, but I found all of them to be weak in one very important aspect. I would like to know your thoughts about this.
IMHO, neither gnusocial, nor Hubzilla, nor diaspora* are handling #federation well. I would, from whatever I read about the systems, expect any pod, hub, or instance to be able to synchronise with all the others. There should be a protocol to gather all posts from all pods, hubs, or servers, not only the ones that someone from your own pod/hub/server has already added.
I opened what is here called the public activity on two different #quitter (a gnusocial installation) servers, only to be shown two entirely different timelines. Not even ten percent were shared content.
Maybe I have the wrong idea of what all this should be or has been made for, but as far as I can tell, social media are in part...

 
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.

jaywink/federation

Python library for abstracting social federation protocols

 

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.

jaywink/federation

Python library for abstracting social federation protocols

 

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.

jaywink/federation

Python library for abstracting social federation protocols

 

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

 
@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

jaywink/nodeinfo2

nodeinfo2 - NodeInfo2 is an effort to create a standardized way of exposing metadata about a server.

 
@Gargron https://talker.to up and running mastodon. Get one more instance to the pool and hopefully support this great project even more. Open registration on talker.to. Hardware will be updated when needed. #talker.to #mastodon #new #instance #gnu #social #talker #federation #xmpp #jabber #mumble greetings to all whoever sees this.

talker.to

TALKER.TO is a secure XMPP/Jabber, Mumble Server. And a Mastodon instance.
REGISTER AN XMPP ACCOUNT BY CLICKING ON THE TALKER.TO LOGO BELOW!

XMPP/Jabber In-band registration is currently disabled.

 
On the Followbot issue: whilst I don't think it's helpful to follow /all/ users on /all/ instances indiscriminantly, picking up the toots of those who've been only recently followed, but have longer histories on their own Instances, would be useful. E.g., @aral seen from mastodon.cloud has only about 22 posts, not the 147 at his home Instance: https://mastodon.social/@aral

This is an automated catch-up feature I think I could endorse.

#followbots #federation #propogation

aral on mastodon.social

Human Rights ★ Social Justice ★ Ethical Design

 
Anyone on #Mastodon can toot me a Content Warning, please? I'm trying to get them to work on #Friendica. Thanks! #Test #Federation

 
hello friends!

i've written down a few ideas, but i would like to get some feedback on what kinds of services you would want from a federation cooperative.

i'm going to be honest, i am trying to get paid here. however, i want to make sure that all of our interests are aligned. i want to provide as much transparency as possible and involve all of you in the process of setting things up and deciding how decisions will be made in the future.

long-term, i hope we can employ some community members (at fair, but competitive salaries) to compensate them for their amazing work. all of our billing and management tools will be licensed AGPL. i encourage any and all enterprising members of the community to start their own cooperative federation networks.

https://source.heropunch.io/bbnet/bbnet/issues
https://riot.im/app/#/room/#bbnet:matrix.org

!fediverse !bbnet #coop #federation

bbnet

all your [social network] are belong to us