social.gl-como.it

Cerca

Elementi taggati con: relay

Improve #federation on #Diaspora with relay servers



It is not easy to enter federation with a small pod (with only few users), because your pod only receives posts from followed users and your post are sent only on pods where someone follows your pod users.

To improve exchange between your pod and others and I recommend to activate relay server in your config/diaspora.yml. It permits to receive posts from other pods even if you are not following any user on these pods (based on tags). It also publishes all your posts to the relay. To avoid to receive all posts, a good choice is to grab posts with pod user followed tags (see scope parameter).

Bigger pods are encouraged to publish their posts on relays to help small pods (outbound: send: true)

Just share this post with your #podmin to be sure #relay server is enabled on your #pod.

Here is a configuration sample extract from config/diaspora.yml :
<br> ## Settings related to relays<br> relay: ## Section<br> <br> ## Relays are applications that exist to push public posts around to<br> ## pods which want to subscribe to them but would not otherwise<br> ## receive them due to not having direct contact with the remote pods.<br> ##<br> ## See more regarding relays: https://wiki.diasporafoundation.org/Relay_servers_for_public_posts<br> <br> outbound: ## Section<br> ## Enable this setting to send out public posts from this pod to a relay<br> send: true<br> ## Change default remote relay url used for sending out here<br> url: 'https://relay.iliketoast.net/receive/public'<br> <br> inbound: ## Section<br> ## Enable this to receive public posts from relays<br> subscribe: true<br> <br> ## Scope is either 'all' or 'tags' (default).<br> ## - 'all', means this pod wants to receive all public posts from a relay<br> ## - 'tags', means this pod wants only posts tagged with certain tags<br> scope: tags<br> <br> ## If scope is 'tags', should we include tags that users on this pod follow?<br> ## These are added in addition to 'pod_tags', if set.<br> include_user_tags: true<br> <br> ## If scope is 'tags', a comma separated list of tags here can be set.<br> ## For example "linux,diaspora", to receive posts related to these tags<br> pod_tags: "diaspora, podmin"<br> <br>
Some clearer explanation here : https://wiki.diasporafoundation.org/Relay_servers_for_public_posts

Bad title - diaspora* project wiki

Bad title - diaspora* project wiki
 

Improve #federation on #Diaspora with relay servers



It is not easy to enter federation with a small pod (with only few users), because your pod only receives posts from followed users and your post are sent only on pods where someone follows your pod users.

To improve exchange between your pod and others and I recommend to activate relay server in your config/diaspora.yml. It permits to receive posts from other pods even if you are not following any user on these pods (based on tags). It also publishes all your posts to the relay. To avoid to receive all posts, a good choice is to grab posts with pod user followed tags (see scope parameter).

Bigger pods are encouraged to publish their posts on relays to help small pods (outbound: send: true)

Just share this post with your #podmin to be sure #relay server is enabled on your #pod.

Here is a configuration sample extract from config/diaspora.yml :
<br> ## Settings related to relays<br> relay: ## Section<br> <br> ## Relays are applications that exist to push public posts around to<br> ## pods which want to subscribe to them but would not otherwise<br> ## receive them due to not having direct contact with the remote pods.<br> ##<br> ## See more regarding relays: https://wiki.diasporafoundation.org/Relay_servers_for_public_posts<br> <br> outbound: ## Section<br> ## Enable this setting to send out public posts from this pod to a relay<br> send: true<br> ## Change default remote relay url used for sending out here<br> url: 'https://relay.iliketoast.net/receive/public'<br> <br> inbound: ## Section<br> ## Enable this to receive public posts from relays<br> subscribe: true<br> <br> ## Scope is either 'all' or 'tags' (default).<br> ## - 'all', means this pod wants to receive all public posts from a relay<br> ## - 'tags', means this pod wants only posts tagged with certain tags<br> scope: tags<br> <br> ## If scope is 'tags', should we include tags that users on this pod follow?<br> ## These are added in addition to 'pod_tags', if set.<br> include_user_tags: true<br> <br> ## If scope is 'tags', a comma separated list of tags here can be set.<br> ## For example "linux,diaspora", to receive posts related to these tags<br> pod_tags: "diaspora, podmin"<br> <br>
Some clearer explanation here : https://wiki.diasporafoundation.org/Relay_servers_for_public_posts

Bad title - diaspora* project wiki

Bad title - diaspora* project wiki
 

Improve #federation on #Diaspora with relay servers



It is not easy to enter federation with a small pod (with only few users), because your pod only receives posts from followed users and your post are sent only on pods where someone follows your pod users.

To improve exchange between your pod and others and I recommend to activate relay server in your config/diaspora.yml. It permits to receive posts from other pods even if you are not following any user on these pods (based on tags). It also publishes all your posts to the relay. To avoid to receive all posts, a good choice is to grab posts with pod user followed tags (see scope parameter).

Bigger pods are encouraged to publish their posts on relays to help small pods (outbound: send: true)

Just share this post with your #podmin to be sure #relay server is enabled on your #pod.

Here is a configuration sample extract from config/diaspora.yml :
<br> ## Settings related to relays<br> relay: ## Section<br> <br> ## Relays are applications that exist to push public posts around to<br> ## pods which want to subscribe to them but would not otherwise<br> ## receive them due to not having direct contact with the remote pods.<br> ##<br> ## See more regarding relays: https://wiki.diasporafoundation.org/Relay_servers_for_public_posts<br> <br> outbound: ## Section<br> ## Enable this setting to send out public posts from this pod to a relay<br> send: true<br> ## Change default remote relay url used for sending out here<br> url: 'https://relay.iliketoast.net/receive/public'<br> <br> inbound: ## Section<br> ## Enable this to receive public posts from relays<br> subscribe: true<br> <br> ## Scope is either 'all' or 'tags' (default).<br> ## - 'all', means this pod wants to receive all public posts from a relay<br> ## - 'tags', means this pod wants only posts tagged with certain tags<br> scope: tags<br> <br> ## If scope is 'tags', should we include tags that users on this pod follow?<br> ## These are added in addition to 'pod_tags', if set.<br> include_user_tags: true<br> <br> ## If scope is 'tags', a comma separated list of tags here can be set.<br> ## For example "linux,diaspora", to receive posts related to these tags<br> pod_tags: "diaspora, podmin"<br> <br>
Some clearer explanation here : https://wiki.diasporafoundation.org/Relay_servers_for_public_posts

Bad title - diaspora* project wiki

Bad title - diaspora* project wiki
 

Improve #federation on #Diaspora with relay servers



It is not easy to enter federation with a small pod (with only few users), because your pod only receives posts from followed users and your post are sent only on pods where someone follows your pod users.

To improve exchange between your pod and others and I recommend to activate relay server in your config/diaspora.yml. It permits to receive posts from other pods even if you are not following any user on these pods (based on tags). It also publishes all your posts to the relay. To avoid to receive all posts, a good choice is to grab posts with pod user followed tags (see scope parameter).

Bigger pods are encouraged to publish their posts on relays to help small pods (outbound: send: true)

Just share this post with your #podmin to be sure #relay server is enabled on your #pod.

Here is a configuration sample extract from config/diaspora.yml :
<br> ## Settings related to relays<br> relay: ## Section<br> <br> ## Relays are applications that exist to push public posts around to<br> ## pods which want to subscribe to them but would not otherwise<br> ## receive them due to not having direct contact with the remote pods.<br> ##<br> ## See more regarding relays: https://wiki.diasporafoundation.org/Relay_servers_for_public_posts<br> <br> outbound: ## Section<br> ## Enable this setting to send out public posts from this pod to a relay<br> send: true<br> ## Change default remote relay url used for sending out here<br> url: 'https://relay.iliketoast.net/receive/public'<br> <br> inbound: ## Section<br> ## Enable this to receive public posts from relays<br> subscribe: true<br> <br> ## Scope is either 'all' or 'tags' (default).<br> ## - 'all', means this pod wants to receive all public posts from a relay<br> ## - 'tags', means this pod wants only posts tagged with certain tags<br> scope: tags<br> <br> ## If scope is 'tags', should we include tags that users on this pod follow?<br> ## These are added in addition to 'pod_tags', if set.<br> include_user_tags: true<br> <br> ## If scope is 'tags', a comma separated list of tags here can be set.<br> ## For example "linux,diaspora", to receive posts related to these tags<br> pod_tags: "diaspora, podmin"<br> <br>
Some clearer explanation here : https://wiki.diasporafoundation.org/Relay_servers_for_public_posts

Bad title - diaspora* project wiki

Bad title - diaspora* project wiki
 

Social-Relay version 1.2.0



New version of the public content #relay server software. This version brings support for passing through also #Diaspora protocol Retraction messages (ie deletions of content). This is important since otherwise a post later deleted that the relay originally delivered would not be delivered. Issues exist in #Diaspora, #Friendica and #Hubzilla issue trackers to get retractions to be sent to the relays.

https://github.com/jaywink/social-relay/releases/tag/1.2.0

Next for the relay system I intend to separate the relay system documentation to it's own repository, since it's not really a part of Social-Relay which is just the server implementing it. Would love to get some opinions on various subjects there then, regarding how to proceed with things like decentralizing the relays and getting rid of the reliance on the-federation.info as a way to bootstrap lists of nodes. Preferably opinions from project admins since the decision on how to decentralize the relays has to be done the way the projects are fine implementing it.

Ping @Davìd M and @Jeremy Pope . Additionally please note the change in the requirement files. I simplified them a bit, changelog has details.

Changelog:

[1.2.0] - 2016-10-25



Added

  • Expose NodeInfo to allow registering relays to pod lists. Unfortunately, NodeInfo schema doesn't contain the relay software key so this NodeInfo document cannot be validated by consumers.
  • Network calls now use a custom user agent Social-Relay/<version> - https://github.com/jaywink/social-relay. Thanks @bmanojlovic for the patch.
  • Relay also Diaspora retraction and photo entities. The former follows the same way like and comment entities are relayed, ie the targets are the same as where the status_message or photo were relayed. photo follows same rules as status_message entities, ie according to subscriber wishes.

Changed

  • Replaced custom payload sending with the new helper from federation. This will not try to deliver to http targets at all. This means nodes that are not using https will not get deliveries. Really, these days, there is no reason to run a public website with http.

Removed

  • Removed suggestion to use pip-tools and convert requirements files to standard Python project requirements files. Didn't dig the workflow after all. To install dev dependencies use requirements/development.txt. For production, use requirements/production.txt, which also contains uWSGI. If you don't deploy using uWSGI, you can just use requirements/requirements.txt.

jaywink/social-relay

social-relay - Public post relay for the Diaspora federated social network protocol
 

Tor: Volunteer - A few things everyone can do nowhttps://www.torproject.org/getinvolved/volunteer.html.en



Immagine/foto
#tor #getinvolved #help #onion #privacy #tails #torbrowser #relay #anonymous #censorship #security #encryption #volunteer

via Diaspora* Publisher -

Tor: Volunteer

Tor is a free software that prevents people from learning your location or browsing habits by letting you communicate anonymously on the Internet. It also helps you bypass censorship online. If you can't open the website, email gettor@torproject.org for instruction on how to get the Tor Browser.
 

Tor: Volunteer - A few things everyone can do nowhttps://www.torproject.org/getinvolved/volunteer.html.en



Immagine/foto
#tor #getinvolved #help #onion #privacy #tails #torbrowser #relay #anonymous #censorship #security #encryption #volunteer

via Diaspora* Publisher -

Tor: Volunteer

Tor is a free software that prevents people from learning your location or browsing habits by letting you communicate anonymously on the Internet. It also helps you bypass censorship online. If you can't open the website, email gettor@torproject.org for instruction on how to get the Tor Browser.
 

Social-Relay version 1.2.0



New version of the public content #relay server software. This version brings support for passing through also #Diaspora protocol Retraction messages (ie deletions of content). This is important since otherwise a post later deleted that the relay originally delivered would not be delivered. Issues exist in #Diaspora, #Friendica and #Hubzilla issue trackers to get retractions to be sent to the relays.

https://github.com/jaywink/social-relay/releases/tag/1.2.0

Next for the relay system I intend to separate the relay system documentation to it's own repository, since it's not really a part of Social-Relay which is just the server implementing it. Would love to get some opinions on various subjects there then, regarding how to proceed with things like decentralizing the relays and getting rid of the reliance on the-federation.info as a way to bootstrap lists of nodes. Preferably opinions from project admins since the decision on how to decentralize the relays has to be done the way the projects are fine implementing it.

Ping @Davìd M and @Jeremy Pope . Additionally please note the change in the requirement files. I simplified them a bit, changelog has details.

Changelog:

[1.2.0] - 2016-10-25



Added

  • Expose NodeInfo to allow registering relays to pod lists. Unfortunately, NodeInfo schema doesn't contain the relay software key so this NodeInfo document cannot be validated by consumers.
  • Network calls now use a custom user agent Social-Relay/<version> - https://github.com/jaywink/social-relay. Thanks @bmanojlovic for the patch.
  • Relay also Diaspora retraction and photo entities. The former follows the same way like and comment entities are relayed, ie the targets are the same as where the status_message or photo were relayed. photo follows same rules as status_message entities, ie according to subscriber wishes.

Changed

  • Replaced custom payload sending with the new helper from federation. This will not try to deliver to http targets at all. This means nodes that are not using https will not get deliveries. Really, these days, there is no reason to run a public website with http.

Removed

  • Removed suggestion to use pip-tools and convert requirements files to standard Python project requirements files. Didn't dig the workflow after all. To install dev dependencies use requirements/development.txt. For production, use requirements/production.txt, which also contains uWSGI. If you don't deploy using uWSGI, you can just use requirements/requirements.txt.

jaywink/social-relay

social-relay - Public post relay for the Diaspora federated social network protocol
 
nuovi vecchi