[HN Gopher] FediDB - Developer Tools for ActivityPub
___________________________________________________________________
FediDB - Developer Tools for ActivityPub
Author : LaSombra
Score : 98 points
Date : 2021-03-22 11:18 UTC (11 hours ago)
(HTM) web link (fedidb.org)
(TXT) w3m dump (fedidb.org)
| nanna wrote:
| Does anyonehave any good guides to setting up ActivityPub for a
| static site like Jekyll?
| riffic wrote:
| you need a certain amount of interactivity for full compliance
| with the protocol.
|
| perhaps someone can provide a sort of managed service to act as
| a backend to support this.
| mariusor wrote:
| What do you expect to gain from setting up ActivityPub for your
| website?
|
| ActivityPub requires some semblance of interactivity for some
| operations, I'm not sure just a static site would qualify.
| aaronpk wrote:
| ActivityPub by definition doesn't work with a static site. But
| check out this project which offloads the ActivityPub parts for
| any site assuming you can make a request there as part of your
| static site build process https://fed.brid.gy/
| a-priori wrote:
| Honestly, I'd suggest reading the specifications directly.
| They're quite well written and have lots of examples.
|
| https://www.w3.org/TR/activitypub/
|
| That said, I'm not sure how much much of ActivityPub you could
| make use of for a static site? You could definitely publish an
| Actor and create an Outbox listing your content. You could also
| have deploy triggers to notify followers when you publish...
|
| But how does someone follow you? In order for that to work,
| there needs to be a server to accept a Follow activity and add
| them to the Followers collection to be notified on publication.
| orblivion wrote:
| Some friendly feedback, if they're reading this:
|
| My profile: I'm someone interested in principle in the fediverse.
| I have a Mastodon account, and plan to expand my footprint when I
| get a chance, maybe install Peertube on my site etc. I'm not a
| developer for anything on it, thus am not familiar with the nuts
| and bolts, but I'm at least curious about it.
|
| With that in mind, I'm not exactly sure what I'm looking at. Is
| this for people writing clients? And what form does this take, a
| software suite? If that's the case I wonder why getting started
| requires an email address. Some parts of the site (list of
| instances, list of software) seem to be very general resources,
| which doesn't give much more of a clue what exactly this is
| about. And then the FAQ answers very specific questions. There's
| a middle ground that feels missing to me.
|
| I do get that this is for helping with testing, and somehow with
| development in general. Is this like an instance that you can
| point your client at, that works like Pixelfed, Mastodon etc, but
| gives more useful error feedback? Saying that explicitly would
| cover what I'm getting at.
|
| Perhaps I'm just not the target market, but it seems like the
| "what is this" test needs a little more to pass _for someone like
| me_.
| gopiandcode wrote:
| I don't think you're the target audience - it's a tool oriented
| at people implementing activitypub servers, and provides a set
| of tools for debugging and testing that an implementation meets
| the activitypub spec. As someone working on an activitypub
| implementation, even without any prior knowledge about the
| tool, from the screenshots and feature list I was immediately
| able to work out what it was for. Things like verifying message
| certificates and activitypub compliance were things that I was
| doing manually in an ad-hoc way before, but this tool seems to
| provide a standard way of testing it.
| mariusor wrote:
| I am part of the target audience (I work on an activitypub
| server and client) but I still don't know what fedidb can do
| to help me.
|
| I don't agree that requiring an account is the only method
| through which you can submit your authorization for the
| domains you want to test against.
|
| Hiding _all_ functionality behind a create account pop-up is
| a pretty dirty pattern.
| [deleted]
| riffic wrote:
| Content management systems picking up support for ActivityPub in
| the same way they currently support RSS will probably result in a
| tipping point for the ecosystem.
| sneak wrote:
| Be careful! The fedivedse is filled with lots of crazies: for
| example, I got dozens of death threats when I built an AP search
| engine/index.
|
| I like decentralized systems but the community is fraught with
| risk. Hopefully that changes as it becomes less niche.
| jitix wrote:
| Maybe we should have something akin to spam filters for
| decentralized social networks.
|
| I personally stopped using mastodon for these reasons.
| sneak wrote:
| I agree, I think published feeds that list items or accounts
| to block (as an advisory) that anyone can subscribe to is the
| future of social media moderation.
|
| Right now it's just instance admins deciding unilaterally for
| their users, which is terrible.
| grishka wrote:
| It's not terrible because you can choose your instance.
| Policies should be a big factor in that choice. If no
| instances suit you, you could as well host your own.
| sneak wrote:
| I do host my own. The admin of one of the most popular
| instances (17k users) has blocked my instance, preventing
| those 17k from seeing me, following me, or DMing me. (It
| also prevents me or any other user of my instance from
| following any of those 17k users.)
|
| This is, quite frankly, a bullshit model that enables
| censorship. An instance admin shouldn't be allowed by the
| protocol to decide who you are allowed to read or follow.
|
| It's just as bullshit when gmail automatically spam-
| folders anyone sending mail to gmail users who isn't part
| of the deliverability cartel. Most gmail users are
| oblivious to the fact that an ad company is managing
| their eyeballs and attention so completely.
| stevenicr wrote:
| This is why I wrote a while back that I think it should
| be sets of 'bouncers' that people subscribe to or
| whatever - and that those bouncers should have profiles
| that people can comment on, clone / fork / etc..
|
| with public transparency (I, sure people could/would want
| and make private bouncers too) - and public comments,
| people could choose to change their blocker/bouncer -
| maybe revert to an older version and clone into a new
| one.
|
| Would be nice to change your choice of censoring based
| upon your own belief/desire rather than being stuck with
| whatever some admin or big G decided to let you see
| without any transparency as to why x y and z are blocked.
|
| I hope this a part of the future that can be built. I too
| am not a fan of the current censoring cartels.
| adenozine wrote:
| Sounds like you run a single user instance? Why should
| any instance be entitled to another instance's users'
| attention, against the will of the admin?
|
| That doesn't make any sense, perhaps you could clarify
| your position here. It seems like you're saying instance
| administrators shouldn't have much control over what
| their users see on the fediverse. That sorta defeats the
| purpose of it, at least the way I use it. If I have to
| let someone else decide for my users, that's hardly
| decentralized. I block single user instances as well,
| because they're usually a waste of time, but if someone
| reaches out and makes a case for a whitelist entry, I
| consider it. That's how it's supposed to be, and that
| aligns with the guarantees about content quality that
| I've offered to users.
|
| Again, I'd love to hear a more detailed description of
| your policy ideas, I don't think I understand.
| sneak wrote:
| > _Why should any instance be entitled to another
| instance 's users' attention, against the will of the
| admin?_
|
| Because those users _want_ to read and follow users on
| that other instance? The instance admin has no right to
| dictate what the users on that server shouldn 't be
| allowed to read or follow.
|
| Users should be in ultimate control of what they are
| allowed to read, not instance admins. Users should be
| able to opt in or out of filter feeds, whether published
| by their local admin or anyone else, at their own option.
|
| This is a fundamental issue with federated networks, one
| that has come up with email and again with AP.
| mariusor wrote:
| If your content is that important for those users, they
| are free to choose a less restrictive instance.
| sodality2 wrote:
| >The instance admin has no right to dictate what the
| users on that server shouldn't be allowed to read or
| follow.
|
| of _course_ they do; they run the server. Whether you
| think they _should_ is a different story.
| shawnz wrote:
| What about when the admins of the most popular "social
| blocklist feeds" decide to put your instance on the block
| list? How is the cartelization problem solved there?
|
| You can say that the blocklists will be voluntary but
| instance participation is already voluntary. Clearly
| that's not enough
| jasode wrote:
| _> An instance admin shouldn't be allowed by the protocol
| to decide who you are allowed to read or follow._
|
| I didn't downvote your comment but how would it even be
| possible using computer science principles to _design a
| protocol that prevents admins from deciding_ what bytes
| go in and out of the machines they pay to run?
|
| Maybe I'm misinterpreting but a simple reading of your
| complaint seems like you're asking for the impossible.
|
| EDIT reply to : _> One method is by end-to-end encrypting
| those bytes, and optionally some of the metadata as
| well._
|
| If there's a hypothetical new ActivityPub version 2.0
| protocol that _encrypts everything_ so that the any and
| all instance operators are _forced_ to accept messages
| and images of sexually abused teen girls, those admins
| _will choose to _not_ to run that encrypted protocol_.
|
| In the end, you still haven't created a protocol that
| removes the ability for _voluntary_ admins to _decide_.
|
| Yes, a limited scenario of 1-to-1 communication where
| encryption hides a conversation between 2 people (e.g.
| Signal) from the instance operator can happen but a
| _1-to-many_ followers broadcast model like Twitter
| /Mastodon/etc with federating/forwarding messages like
| USENET is different. How would a protocol for 1-to-many
| _force_ admins to accept those bytes?
|
| EDIT reply to: _> Yet people are still using freenet._
|
| Yes, of course _some_ are running Freenet. But that
| doesn't address my point: you can't design a protocol
| that _forces_ humans (aka "admins") to accept any and all
| bytes. There are many that choose to _not_ run Freenet.
| h_anna_h wrote:
| > to design a protocol that prevents admins from deciding
| what bytes go in and out of the machines they pay to run?
|
| By designing a peer to peer protocol without admins.
|
| > those admins will choose to _not_ to run that encrypted
| protocol.
|
| Yet people are still using freenet. Regardless, you can
| run a protocol like this on top of AP, to the admin it
| will look as if people are just exchanging encrypted
| data.
| grishka wrote:
| > By designing a peer to peer protocol without admins.
|
| You can't require a client app for a social media service
| if you want any adoption. It's extremely important to
| allow at least viewing the content via a regular web
| browser. And to allow that to be done natively and
| frictionlessly, without having to rely on protocol
| bridges.
|
| I can send a link to a Mastodon post wherever to
| whomever, even if they have never heard about Mastodon.
| Can't do that with p2p networks.
| sneak wrote:
| One method is by end-to-end encrypting those bytes, and
| optionally some of the metadata as well.
| mariusor wrote:
| I think that in the case of Public activities you'll be
| missing one end.
| grishka wrote:
| It's only a matter of time before spam becomes a problem in
| fediverse. Any system that is open and popular enough will
| inevitably attract bad actors.
| polytely wrote:
| I think it will be less of a problem then for example on
| twitter , because you can just mute/block/defederate
| instances that aren't able to control the spam on their
| instance. There is an incentive to stay small enough so
| that the mod team can keep up with the amount of work
| required to keep the community relatively spam free.
|
| Unlike twitter there aren't investors that want to keep
| growing endlessly so the hard problem of moderation at
| scale can just be sidestepped by the admin by closing
| instance signups once they reach moderation capacity.
| eeZah7Ux wrote:
| I had only very good interactions on Mastodon. It's been the
| best social network I've ever seen so far.
| tuyguntn wrote:
| > I got dozens of death threats when I built an AP search
|
| Do you have any idea why? conspirologist in me says, this could
| be targeted attack by FB, Twitter to slow down decentralized
| movement. But I don't want to give my inner conspirologist take
| over my mind.
| sneak wrote:
| Some people think that they can publish information to the
| unauthenticated web and simultaneously have that information
| remain, in some sense, under their own control. This belief
| is false.
|
| There is a desire to be able to sort of soft-publish,
| accessible to the whole internet, but revocable in some way.
| That's not how publishing works from an information-
| theoretical standpoint, to say nothing of the internet.
|
| A lot of people thought their data was being stolen or
| misappropriated when their own servers provided it to me via
| unauthenticated vanilla HTTP requests to public URLs.
|
| It sometimes occurs to me that if search engines didn't
| exist, and you tried to invent them today, profiting off of a
| downloaded copy of the full text of other people's websites,
| you would be sued into oblivion.
| thejohnconway wrote:
| From what I've been reading, a there is a large contingent in
| the Fediverse that is against people being easily found. This
| is due to fears of of harassment and stalking.
|
| I think this is not a sustainable view. It is trivial to
| write a crawler to find people's profiles using open APIs,
| and even more could be garnered if you scrape pages.
|
| If you don't want to be found but must put stuff on the
| internet, the answer is to not federate.
___________________________________________________________________
(page generated 2021-03-22 23:02 UTC)